On Inheriting and Sharing Property Values

Generally I need to set the worth of a CSS property to that of a unique property, even when I don’t know what that worth is, and even when it modifications later. Sadly although, that’s not attainable (a minimum of, there isn’t a CSS perform that particularly does that).

In my view, it’d be tremendous helpful to have one thing like this (for interpolation, possibly you’d throw calc-size() in there as effectively):

/* Completely hypothetical */
button {
  border-radius: compute(top, self);
  border-radius: compute(top, inherit);
  border-radius: compute(top, #this);
}

In 2021, Lea Verou defined why, regardless of being proposed quite a few occasions, implementing such a general-purpose CSS perform like this isn’t possible. Having stated that, I do stay hopeful, as a result of issues are all the time evolving and the CSSWG course of isn’t all the time linear.

Within the meantime, although there isn’t a CSS perform that permits us to get the worth of a unique property, you may have the ability to obtain your final result utilizing a unique methodology, and people strategies are what we’re going to have a look at at the moment.

The fool-proof CSS customized properties methodology

We are able to simply get the worth of a unique CSS property utilizing customized properties, however we’d must know what the worth is with a purpose to declare the customized property to start with. This isn’t supreme, but it surely does allow us to attain some outcomes.

Let’s bounce again to the instance from the intro the place we attempt to set the border-radius primarily based on the top, solely this time we all know what the peak is and we retailer it as a CSS customized property for reusability, and so we’re capable of obtain our final result:

button {
  --button-height: 3rem;
  top: var(--button-height);
  border-radius: calc(var(--button-height) * 0.3);
}

We are able to even place that --button-height customized property larger up within the CSS cascade to make it accessible to extra containment contexts.

:root {
  /* Declare right here to make use of wherever */
  --button-height: 3rem;

  header {
    --header-padding: 1rem;
    padding: var(--header-padding);
  
    /* Peak is unknown (however we are able to calculate it) */
    --header-height: calc(var(--button-height) + (var(--header-padding) * 2));
  
    /* Which implies we are able to calculate this, too */
    border-radius: calc(var(--header-height) * 0.3);
  
    button {
      /* In addition to these, in fact */
      top: var(--button-height);
      border-radius: calc(var(--button-height) * 0.3);

      /* Oh, what the heck */
      padding-inline: calc(var(--button-height) * 0.5);
    }
  }
}

I suppose when my math trainer stated that I’d want algebra someday. She wasn’t mendacity!

The unsupported inherit() CSS perform methodology

The inherit() CSS perform, which isn’t at present supported by any internet browser, will allow us to get the worth of a dad or mum’s property. Assume: the inherit key phrase, besides that we are able to get the worth of any dad or mum property and even modify it utilizing worth features resembling calc(). The newest draft of the CSS Values and Items Module Stage 5 spec defines how this’d work for customized properties, which wouldn’t actually allow us to do something that we are able to’t already do (as demonstrated within the earlier instance), however the hope is that it’d work for all CSS properties additional down the road in order that we wouldn’t want to make use of customized properties (which is only a tad longer):

header {
  top: 3rem;

  button {
    top: 100%;

    /* Get top of dad or mum however use it right here */
    border-radius: calc(inherit(top) * 0.3);
    padding-inline: calc(inherit(top) * 0.5);
  }
}

There’s one distinction between this and the customized properties method, although. This methodology relies on the fastened top of the dad or mum, whereas with the customized properties methodology both the dad or mum or the kid can have the fastened top.

Because of this inherit() wouldn’t interpolate values. For instance, an auto worth that computes to 3rem would nonetheless be inherited as auto, which could compute to one thing else when inherit()-ed., Generally that’d be high quality, however different occasions it’d be a difficulty. Personally, I’m hoping that interpolation turns into a risk in some unspecified time in the future, making it way more helpful than the customized properties methodology.

Till then, there are another (largely property-specific) choices.

The aspect-ratio CSS property

Utilizing the aspect-ratio CSS property, we are able to set the peak relative to the width, and vice-versa. For instance:

div {
  width: 30rem;

  /* top will probably be half of the width */
  aspect-ratio: 2 / 1;

  /* Identical factor */
  aspect-ratio: 3 / 1.5;

  /* Identical factor */
  aspect-ratio: 10 / 5;

  /* width and top would be the similar */
  aspect-ratio: 1 / 1;
}

Technically we don’t “get” the width or the top, however we do get to set one primarily based on the opposite, which is the necessary factor (and because it’s a ratio, you don’t must know the precise worth — or unit — of both).

The currentColor CSS key phrase

The currentColor CSS key phrase resolves to the computed worth of the colour property. Its knowledge sort is <colour>, so we are able to use it instead of any <colour> on any property on the identical ingredient. For instance, if we set the colour to purple (or one thing that resolves to purple), or if the colour is computed as purple by way of inheritance, we may then declare border-color: currentColor to make the border purple too:

physique {
  /* We are able to set colour right here (and let it's inherited) */
  colour: purple;

  button {
    /* Or set it right here */
    colour: purple;

    /* After which use currentColor right here */
    border-color: currentColor;
    border: 0.0625rem strong currentColor;
    background: hsl(from currentColor h s 90);
  }
}

This permits us to reuse the colour with out having to arrange customized properties, and naturally if the worth of colour modifications, currentColor will routinely replace to match it.

Whereas this isn’t the identical factor as having the ability to get the colour of actually something, it’s nonetheless fairly helpful. Really, if one thing akin to compute(background-color) simply isn’t attainable, I’d be proud of extra CSS key phrases like currentColor.

The truth is, currentBackgroundColor/currentBackground has already been proposed. Utilizing currentBackgroundColor for instance, we may set the border colour to be barely darker than the background colour (border-color: hsl(from currentBackgroundColor h s calc(l - 30))), or combine the background colour with one other colour after which use that because the border colour (border-color: color-mix(currentBackgroundColor, black, 30)).

However why cease there? Why not currentWidth, currentHeight, and so forth?

The from-font CSS key phrase

The from-font CSS key phrase is unique to the text-decoration-thickness property, which can be utilized to set the thickness of underlines. When you’ve ever hated the truth that underlines are all the time 1px whatever the font-size and font-weight, then text-decoration-thickness can repair that.

The from-font key phrase doesn’t generate a worth although — it’s optionally offered by the font maker and embedded into the font file, so that you may not like the worth that they supply, if they supply one in any respect. In the event that they don’t, auto will probably be used as a fallback, which internet browsers resolve to 1px. That is high quality when you aren’t choosy, but it surely’s nonetheless unreliable (and clearly fairly area of interest).

We are able to, nevertheless, specify a share worth as an alternative, which can be sure that the thickness is relative to the font-size. So, if text-decoration-thickness: from-font simply isn’t chopping it, then we’ve that as a backup (one thing between 8% and 12% ought to do it).

Don’t underestimate CSS items

You in all probability already learn about vw and vh items (viewport width and viewport top items). These characterize a share of the viewport’s width and top respectively, so 1vw for instance could be 1% of the viewport’s width. These items might be helpful by themselves or inside a calc() perform, and used inside any property that accepts a <size> unit.

Nevertheless, there are many different, lesser-known items that may be helpful in an identical manner:

• 1ex: equal to the computed x-height
• 1cap: equal to the computed cap top
• 1ch: equal to the computed width of the 0 glyph
• 1lh: equal to the computed line-height (so long as you’re not trimming or including to its content material field, for instance utilizing text-box or padding, respectively, lh items might be used to find out the peak of a field that has a hard and fast variety of strains)

And once more, you should utilize them, their logical variants (e.g., vi and vb), and their root variants (e.g., rex and rcap) inside any property that accepts a <size> unit.

As well as, when you’re utilizing container dimension queries, you’re additionally free to make use of the next container question items throughout the containment contexts:

• 1cqw: equal to 1% of the container’s computed width
• 1cqh: equal to 1% of the container’s computed top
• 1cqi: equal to 1% of the container’s computed inline dimension
• 1cqb: equal to 1% of the container’s computed block dimension
• 1cqmin: equal to 1cqi or 1cqb, whichever is smallest
• 1cqmax: equal to 1cqi or 1cqb, whichever is largest

That inherit() instance from earlier, , the one which isn’t at present supported by any internet browser? Right here’s the identical factor however with container dimension queries:

header {
  top: 3rem;
  container: header / dimension;

  @container header (width) {
    button {
      top: 100%;
      border-radius: calc(100cqh * 0.3);
      padding-inline: calc(100cqh * 0.5);
    }
  }
}

Or, since we’re speaking a few container and its direct little one, we are able to use the next shorter model that doesn’t create and question a named container (we don’t want to question the container anyway, since all we’re doing is stealing its items!):

header {
  top: 3rem;
  container-type: dimension;

  button {
    top: 100%;
    border-radius: calc(100cqh * 0.3);
    padding-inline: calc(100cqh * 0.5);
  }
}

Nevertheless, take into account that inherit() would allow us to inherit something, whereas container dimension queries solely allow us to inherit sizes. Additionally, container dimension queries don’t work with inline containers (that’s why this model of the container is horizontally stretched), to allow them to’t resolve each downside anyway.

In a nutshell

I’m simply going to throw compute() on the market once more, as a result of I feel it’d be a very nice solution to get the values of different CSS properties:

button {
  /* self might be the default */
  border-radius: compute(top, self);
  /* inherit may work like inherit() */
  border-radius: compute(top, inherit);
  /* Good to have, however not as necessary */
  border-radius: compute(top, #this);
}

But when it’s simply not attainable, I actually like the concept of introducing extra currentColor-like key phrases. Except key phrases like from-font the place the font maker gives the worth (or not, sigh), key phrases resembling currentWidth and currentHeight could be extremely helpful. They’d make CSS simpler to learn, and we wouldn’t need to create as many customized properties.

Within the meantime although, customized properties, aspect-ratio, and sure CSS items will help us in the appropriate circumstances, to not point out that we’ll be getting inherit() sooner or later. These are closely geared in the direction of getting widths and heights, which is ok as a result of that’s undoubtedly the largest downside right here, however hopefully there are extra CSS options on the horizon that enable values for use in additional locations.