CSS-TRICKS

<p>How far can we really go with container queries? There are dozens of media queries now, so what if there were dozens of container queries as well? What could we use them for?</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/what-else-could-container-queries-query/">What Else Could Container Queries&#8230; Query?</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>I’ll admit, when container queries first shipped back in 2022, I didn’t really pay attention. I mean, why <a href="https://css-tricks.com/smart-layouts-with-container-queries/">container size queries</a> when we already have <a href="https://css-tricks.com/a-complete-guide-to-css-media-queries/">media queries</a>? Why <a href="https://css-tricks.com/digging-deeper-into-container-style-queries/">container style queries</a> when custom properties inherit anyway (they don’t work with standard properties… <em>yet</em>)? Their use cases seemed like edge cases to me, enabling us to do things that we could already do but in a different way.</p>



<span id="more-390654"></span>



<p>Here&#8217;s a container size queries demo by <a href="https://css-tricks.com/author/kevinpowell/">Kevin Powell</a>. As a note, all major browsers support size queries in the following demo, but other demos in this article may require the latest Chrome.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_NWZgQwE" src="//codepen.io/anon/embed/NWZgQwE?height=450&amp;theme-id=1&amp;slug-hash=NWZgQwE&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed NWZgQwE" title="CodePen Embed NWZgQwE" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>Container style queries (with the new <a href="https://css-tricks.com/the-range-syntax-has-come-to-container-style-queries-and-if/">range syntax</a>) demo by, <em>uh</em>, me:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_raxpXLO" src="//codepen.io/anon/embed/raxpXLO?height=450&amp;theme-id=1&amp;slug-hash=raxpXLO&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed raxpXLO" title="CodePen Embed raxpXLO" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>And more recently, we’ve seen a couple more types of container queries pop up.</p>


<h3 class="wp-block-heading" id="container-scroll-state-queries">Container Scroll-State Queries</h3>


<p>Container scroll-state queries came along with their unique capabilities — the ability to find out whether a container is scrollable, or is scroll-snapped to a scroll target, or has <code>position: sticky</code> and is ‘stuck.’ Literally, as I’m writing this, Chrome announced <a href="https://developer.chrome.com/blog/chrome-144-beta?hl=en#scroll-state_scrolled_support" rel="noopener"><code>scrolled</code> support</a>, which is a bit different to <code>scrollable</code>.</p>



<p>Container scroll-state queries demo by our very own <a href="https://css-tricks.com/author/geoffgraham/">Geoff Graham</a>:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_OPLwNma" src="//codepen.io/anon/embed/OPLwNma?height=450&amp;theme-id=1&amp;slug-hash=OPLwNma&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed OPLwNma" title="CodePen Embed OPLwNma" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>And that’s not all we’ve got…</p>


<h3 class="wp-block-heading" id="anchored-container-queries">Anchored container queries</h3>


<p>The latest container query feature is <a href="https://developer.chrome.com/blog/anchored-container-queries" rel="noopener">anchored container queries</a>, which enable us to query fallback positions. Imagine that you anchor-position a tooltip caret to the left side of a tooltip, but then there’s no room to display the tooltip, so you flip it to the opposite side of whatever triggers it using <code>position-try-fallbacks: flip-inline</code>. Well, an anchored container query can detect when the tooltip position is flipped so that we can also flip the tooltip caret to the opposite side of the tooltip.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_gbrMGYx" src="//codepen.io/anon/embed/gbrMGYx?height=450&amp;theme-id=1&amp;slug-hash=gbrMGYx&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed gbrMGYx" title="CodePen Embed gbrMGYx" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="what-else-">What else?</h3>


<p>So, it got me thinking, <em>how far can we really go with container queries?</em> <a href="https://css-tricks.com/a-complete-guide-to-css-media-queries/">There are dozens of media queries now</a>, so what if there were dozens of container queries as well? What could we use them for?</p>


<h4 class="wp-block-heading" id="get-any-computed-value">Get any computed value</h4>


<p>Recently I was exploring <a href="https://css-tricks.com/on-inheriting-and-sharing-property-values/">the current and future methods of getting the value of a CSS property and using it with another property</a>, and as you can imagine, container size queries were mentioned since they unlock <a href="https://css-tricks.com/css-length-units/#relative-units">container query units</a>. I mean, have you ever added a wrapper element or defined an existing one as a container just to access container query units?</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">&lt;parent> {
  /* Gimme container query units! */
  container-type: inline-size;

  &lt;child> {
    width: 100cqi;
  }
}</code></pre>



<p>Now, I don’t love container queries as a means of getting values because the syntax can be a bit long-winded for that (longer than the example above, and size queries in particular are a bit quirky), but the fact that we can use them to do a little more than querying is testament to how versatile they are as a feature. As an alternative, <a href="https://css-tricks.com/on-inheriting-and-sharing-property-values/">I suggested a CSS function</a> called <code>compute()</code>, where if you wanted the <code>height</code> of something (or the “something” of anything), we could steal it from another element like this:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">&lt;parent> {
  &lt;child> {
    /* Computed height of &lt;child> */
    property: compute(height, self);
    /* Computed height of the parent */
    property: compute(height, inherit);
    /* Computed height of #abc element */
    property: compute(height, #abc);
  }
}</code></pre>



<p>This would save us from having to implement a container size query just to use its container query units, and would also apply to all properties. Besides, a container size query wouldn’t help us to acquire the un-computed declared value that we actually typed out. For that, the <code>inherit()</code> function has been proposed and <a href="https://blog.kizu.dev/play-with-inherit-function/" rel="noopener">Roma even shows us how to use it</a> in Chrome Canary.</p>



<p>To add, I really like the keyword approach and would love to see more keywords like <a href="https://css-tricks.com/currentcolor/"><code>currentColor</code></a> (e.g., <a href="https://github.com/w3c/csswg-drafts/issues/5292" rel="noopener"><code>currentBackgroundColor</code> has been proposed</a>).</p>



<p>Still, if container queries could be extended to get the value of <em>any</em> CSS property, I definitely wouldn’t say no to that! The flexibility to pass properties/values between elements is way too enticing.</p>


<h4 class="wp-block-heading" id="query-any-css-property">Query any CSS property</h4>


<p>This feature has actually been on the slate since container style queries were first proposed, but there’s no telling when it will arrive. This container style query upgrade will enable us to query the (un-computed/declared) value of any CSS property instead of just custom properties (although you won’t be able to ‘get’ and use those values, at least as far as I know).</p>



<p><em>Any</em> CSS property? Uh, doesn’t that make all of the other container queries redundant? Not quite, no.</p>



<p>Container scroll-state queries detect snapping and stickiness, for which there are no pseudo-classes — but maybe there should be? They also detect scrollability, since, for example, <code>overflow: scroll</code> and <code>overflow: visible</code> doesn’t mean that the content is actually overflowing, only that we’re allowed to scroll the container if it does. Finally, anchored container queries don’t query the <code>position-try-fallbacks</code> value, they detect <em>when</em>, for example, the <code>position-area</code> is flipped.</p>



<p>So, you know, they do a whole bunch of stuff, and that’s why this upgrade for container style queries won’t replace them. In fact, I can totally see dozens of new container query features hitting the web within the next few years.</p>


<h4 class="wp-block-heading" id="so-what-else-could-container-queries-do-">So, what else could container queries do?</h4>


<p>Before container queries were even a thing, great ideas were being put forward. Of course, some of them actually became container queries whereas others are still just that — great ideas that haven’t gone anywhere (again&#8230;<em>yet?</em>).</p>



<ul class="wp-block-list">
<li><a href="https://github.com/w3c/csswg-drafts/issues/5989#issuecomment-783702864" rel="noopener">Adam Argyle suggested</a> some interesting things that would later become scroll-state queries, in addition to being able to query whether something’s on-screen, wrapping, or ellipsing, which I’d love to see.</li>



<li><a href="https://github.com/w3c/csswg-drafts/issues/5989#issuecomment-858739994" rel="noopener">Adam also suggested being able to count child nodes</a>, an idea that later became <code>sibling-count()</code> and <code>sibling-index()</code>, although I&#8217;d still like to see the container query approach.</li>



<li>In a similar vein, Matthew Dean pointed out that <a href="https://github.com/w3c/csswg-drafts/issues/6402#issuecomment-1094141090" rel="noopener">some container queries could instead or also be pseudo-classes</a>, which I agree with. Matthew also suggested that <a href="https://github.com/w3c/csswg-drafts/issues/6402#issuecomment-1094140594" rel="noopener">container queries could be used to query whether a flex container is wrapped</a>, and which row/column of a flexbox/grid container we’re in.</li>
</ul>



<p>I’m confident that we’ll see these ideas realized at some point, either as container queries or as some other syntax. Heck, since it&#8217;s December, I&#8217;ll make it my prediction for 2026: container queries will rule 2026.</p>



<p>What else do <em>you</em> want container queries to do?</p>


<h3 class="wp-block-heading" id="references">References</h3>


<ul class="wp-block-list">
<li><a href="https://ishadeed.com/article/css-container-query-guide/" rel="noopener">Learn container queries with interactive examples</a> (Ahmad Shadeed)</li>



<li><a href="https://developer.chrome.com/blog/anchored-container-queries" rel="noopener">Detect fallback positions with anchored container queries from Chrome 143</a> (Una Kravets)</li>



<li><a href="https://blog.kizu.dev/play-with-inherit-function/" rel="noopener">Play With Inherit Function</a> (Roma Komarov)</li>



<li><a href="https://css-tricks.com/on-inheriting-and-sharing-property-values/">On Inheriting and Sharing Property Values</a> (Daniel Schwarz)</li>



<li><a href="https://caniuse.com/?search=container+queries" rel="noopener">Browser support for current and future container queries</a> (CanIUse)</li>
</ul>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/what-else-could-container-queries-query/">What Else Could Container Queries&#8230; Query?</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


I’ll admit, when container queries first shipped back in 2022, I didn’t really pay attention. I mean, why container size queries when we already have media queries? Why container style queries when custom properties inherit anyway (they don’t work with standard properties… yet)? Their use cases seemed like edge cases to me, enabling us to do things that we could already do but in a different way.




Here’s a container size queries demo by Kevin Powell. As a note, all major browsers support size queries in the following demo, but other demos in this article may require the latest Chrome.
CodePen Embed Fallback
Container style queries (with the new range syntax) demo by, uh, me:
CodePen Embed Fallback
And more recently, we’ve seen a couple more types of container queries pop up.
Container Scroll-State Queries
Container scroll-state queries came along with their unique capabilities — the ability to find out whether a container is scrollable, or is scroll-snapped to a scroll target, or has position: sticky and is ‘stuck.’ Literally, as I’m writing this, Chrome announced scrolled support, which is a bit different to scrollable.
Container scroll-state queries demo by our very own Geoff Graham:
CodePen Embed Fallback
And that’s not all we’ve got…
Anchored container queries
The latest container query feature is anchored container queries, which enable us to query fallback positions. Imagine that you anchor-position a tooltip caret to the left side of a tooltip, but then there’s no room to display the tooltip, so you flip it to the opposite side of whatever triggers it using position-try-fallbacks: flip-inline. Well, an anchored container query can detect when the tooltip position is flipped so that we can also flip the tooltip caret to the opposite side of the tooltip.
CodePen Embed Fallback
What else?
So, it got me thinking, how far can we really go with container queries? There are dozens of media queries now, so what if there were dozens of container queries as well? What could we use them for?
Get any computed value
Recently I was exploring the current and future methods of getting the value of a CSS property and using it with another property, and as you can imagine, container size queries were mentioned since they unlock container query units. I mean, have you ever added a wrapper element or defined an existing one as a container just to access container query units?
<parent> {
  /* Gimme container query units! */
  container-type: inline-size;

  <child> {
    width: 100cqi;
  }
}
Now, I don’t love container queries as a means of getting values because the syntax can be a bit long-winded for that (longer than the example above, and size queries in particular are a bit quirky), but the fact that we can use them to do a little more than querying is testament to how versatile they are as a feature. As an alternative, I suggested a CSS function called compute(), where if you wanted the height of something (or the “something” of anything), we could steal it from another element like this:
<parent> {
  <child> {
    /* Computed height of <child> */
    property: compute(height, self);
    /* Computed height of the parent */
    property: compute(height, inherit);
    /* Computed height of #abc element */
    property: compute(height, #abc);
  }
}
This would save us from having to implement a container size query just to use its container query units, and would also apply to all properties. Besides, a container size query wouldn’t help us to acquire the un-computed declared value that we actually typed out. For that, the inherit() function has been proposed and Roma even shows us how to use it in Chrome Canary.
To add, I really like the keyword approach and would love to see more keywords like currentColor (e.g., currentBackgroundColor has been proposed).
Still, if container queries could be extended to get the value of any CSS property, I definitely wouldn’t say no to that! The flexibility to pass properties/values between elements is way too enticing.
Query any CSS property
This feature has actually been on the slate since container style queries were first proposed, but there’s no telling when it will arrive. This container style query upgrade will enable us to query the (un-computed/declared) value of any CSS property instead of just custom properties (although you won’t be able to ‘get’ and use those values, at least as far as I know).
Any CSS property? Uh, doesn’t that make all of the other container queries redundant? Not quite, no.
Container scroll-state queries detect snapping and stickiness, for which there are no pseudo-classes — but maybe there should be? They also detect scrollability, since, for example, overflow: scroll and overflow: visible doesn’t mean that the content is actually overflowing, only that we’re allowed to scroll the container if it does. Finally, anchored container queries don’t query the position-try-fallbacks value, they detect when, for example, the position-area is flipped.
So, you know, they do a whole bunch of stuff, and that’s why this upgrade for container style queries won’t replace them. In fact, I can totally see dozens of new container query features hitting the web within the next few years.
So, what else could container queries do?
Before container queries were even a thing, great ideas were being put forward. Of course, some of them actually became container queries whereas others are still just that — great ideas that haven’t gone anywhere (again…yet?).
Adam Argyle suggested some interesting things that would later become scroll-state queries, in addition to being able to query whether something’s on-screen, wrapping, or ellipsing, which I’d love to see.
Adam also suggested being able to count child nodes, an idea that later became sibling-count() and sibling-index(), although I’d still like to see the container query approach.
In a similar vein, Matthew Dean pointed out that some container queries could instead or also be pseudo-classes, which I agree with. Matthew also suggested that container queries could be used to query whether a flex container is wrapped, and which row/column of a flexbox/grid container we’re in.
I’m confident that we’ll see these ideas realized at some point, either as container queries or as some other syntax. Heck, since it’s December, I’ll make it my prediction for 2026: container queries will rule 2026.
What else do you want container queries to do?
References
Learn container queries with interactive examples (Ahmad Shadeed)
Detect fallback positions with anchored container queries from Chrome 143 (Una Kravets)
Play With Inherit Function (Roma Komarov)
On Inheriting and Sharing Property Values (Daniel Schwarz)
Browser support for current and future container queries (CanIUse)
What Else Could Container Queries… Query? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

How far can we really go with container queries? There are dozens of media queries now, so what if there were dozens of container queries as well? What could we use them for?
What Else Could Container Queries… Query? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What Else Could Container Queries… Query?

<p>It’s not that hard to do! Preethi shows you how it's really the same old animation you’re used to writing in CSS, only applied on a view timeline instead of a normal timeline.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/creating-scroll-based-animations-in-full-view/">Creating Scroll-Based Animations in Full view()</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>The CSS <a href="https://css-tricks.com/almanac/properties/a/animation-timeline/"><code>animation-timeline</code></a> property accepts a <code>view()</code> function which, in turn, returns a timeline of how much of an element is visible in the part of a scroll container that’s viewable (formally known as a <em>scrollport</em>). In other words, rather than letting an animation run a linear progression based on how much time has elapsed, <code>view()</code> runs animations based on the visibility of the animated element within a scrollport.</p>



<p>I like to equate it as the CSS version of JavaScript’s <a href="https://css-tricks.com/an-explanation-of-how-the-intersection-observer-watches/">Intersection Observer</a>. We can run an animation on an element as that element enters and exits the scrollport.</p>



<span id="more-390516"></span>



<p>Here’s an example:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_emZmBwQ" src="//codepen.io/anon/embed/emZmBwQ?height=450&amp;theme-id=1&amp;slug-hash=emZmBwQ&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed emZmBwQ" title="CodePen Embed emZmBwQ" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<figure class="wp-block-video"><video height="886" style="aspect-ratio: 1400 / 886;" width="1400" controls src="https://css-tricks.com/wp-content/uploads/2025/11/scroll-animation-carousel.mov" playsinline></video></figure>



<p>Pretty neat, right? Depending on <em>where</em> an image is in the scrollable carousel, it goes from small and blurry at the far sides while getting larger and clearer when it hits the center. We have a little <a href="https://css-tricks.com/practical-css-scroll-snapping/">scroll snapping</a> in there as well to make sure each image item makes a stop.</p>



<p>It’s not that hard to do! I’ll show you how it&#8217;s really the same old animation you’re used to writing in CSS, only applied on a view timeline instead of a normal timeline.</p>


<h3 class="wp-block-heading" id="but-first-the-general-layout">But first, the general layout</h3>


<p>All I’m making here is an element I’m calling <code>.carousel</code>:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;main class="carousel">
  &lt;!-- scroll items -->
&lt;/main></code></pre>



<p>The elements in <code>.carousel</code> will lay out in a single row, which is a one-liner with flexbox. We’ll also make sure that any content overflowing its space is scrollable:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.carousel {
  display: flex;
  width: max(480px, 50vw);
  overflow-x: auto;
}</code></pre>



<p>And, of course, we need items in it that we can scroll around. A set of image slides.</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;main class="carousel">
  &lt;div class="carousel-slide">
    &lt;!-- (optional) empty bookend slide -->
  &lt;/div>
  &lt;div class="carousel-slide">
      &lt;img src="image-1.jpeg" alt="alt text for image 1">
  &lt;/div>
  &lt;div class="carousel-slide">
      &lt;img src="image-2.jpeg" alt="alt text for image 2">
  &lt;/div>
  &lt;!-- etc -->
  &lt;div class="carousel-slide">
    &lt;!-- (optional) empty bookend slide -->
  &lt;/div>
&lt;/main></code></pre>



<p>As far as styling those items, each one will be one-third the size of the available space so that we see three items at a time when scrolling:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.carousel {
  /* same as before */

  .carousel-slide {
    flex-shrink: 0;
    width: calc(100% / 3); /* show three at a time */
    aspect-ratio: .8;
    img {
      width: 100%;
    }
  }
}</code></pre>


<h3 class="wp-block-heading" id="then-the-scrolling">Then the scrolling</h3>


<p>We’ve already set <code>overflow-x</code> on the <code>.carousel</code>, officially making it our scroll container. We can drop in a little scroll snapping to make sure we’re only scrolling one item at a time.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.carousel {
  /* same as before */

  scroll-snap-type: x mandatory;
  scroll-behavior: smooth; /* optional for smooth scrolling */
  scrollbar-width: none; /* optional to hide the scrollbar */
}</code></pre>



<p>We want to make sure that the slides are aligned to the center of the scroll container when snapping into place:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.carousel-slide {
  /* etc. */
  scroll-snap-align: center;
}</code></pre>



<p>Here’s what we have so far:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_yyOXZPa" src="//codepen.io/anon/embed/yyOXZPa?height=450&amp;theme-id=1&amp;slug-hash=yyOXZPa&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed yyOXZPa" title="CodePen Embed yyOXZPa" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="next-the-animation">Next, the animation</h3>


<p>Here’s the really cool thing I mentioned at the very start: a view timeline animation is really the same thing as any other CSS animation you write with keyframes. In this case, we want keyframes where the carousel items are small and blurry at the start and end, but become larger and clearer right smack dab in the middle of the animation.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">@keyframes slide {
  /* from start to 45%, and to the end (100%) */
  45%, 100% {
    transform: scale(0.5);
    border-radius: 20px;
    filter: blur(6px) brightness(.8);
  }
  /* middle */
  50% {
    transform: scale(1);
    border-radius: 4px;
    filter: none;
  }
}</code></pre>



<p>Looks familiar, right? This is the sort of CSS you’ve been writing forever! And guess what? We set the animation on the element we’re animating just as you normally would as well:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.carousel-slide {
  /* etc. */
  animation: slide; 
}</code></pre>



<p>The only difference is that we want the animation to run on a timeline based on the element’s current <code>view()</code> instead of the regular timeline. That’s where the <code>animation-timeline</code> property comes into play:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.carousel-slide {
  /* etc. */
  animation: slide; 
  animation-timeline: view(inline);
}</code></pre>



<p>Now, <em>technically</em> speaking, we could slap that timeline directly in the <code>animation</code> shorthand property like any other constituent animation property, e.g., <code>animation-name</code>, <code>animation-delay</code>, <code>animation-duration</code>, etc. But assigning a timeline function this way is not supported by any browsers yet. So, for now, your best bet is to declare it on its own. Just be sure to declare it <em>after</em> the <code>animation</code> shorthand, or else you may find yourself inadvertently overriding your view timeline with <code>auto</code> (the default property value) instead of <code>view()</code>.</p>



<p>That completes our demo:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_emZmBwQ" src="//codepen.io/anon/embed/emZmBwQ?height=450&amp;theme-id=1&amp;slug-hash=emZmBwQ&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed emZmBwQ" title="CodePen Embed emZmBwQ" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<figure class="wp-block-video"><video height="886" style="aspect-ratio: 1400 / 886;" width="1400" controls src="http://css-tricks.com/wp-content/uploads/2025/11/scroll-animation-carousel.mov" playsinline></video></figure>



<p>See that? All we’ve really done is set a CSS animation that runs on elements. However, instead of running on the default timeline, the animation runs when an element scrolls in and out of view. That’s the difference between standard and view timelines.</p>


<h3 class="wp-block-heading" id="-view-vs-scroll-"><code>view()</code> vs. <code>scroll()</code></h3>


<p><em>But wait!</em> You may or may not know that <code>view()</code> timelines are part of a larger feature set called <a href="https://css-tricks.com/unleash-the-power-of-scroll-driven-animations/">CSS Scroll-Driven Animations</a>. And <code>view()</code> is not the only function supported by the <code>animation-timeline</code> property. We also have the <code>scroll()</code> function.</p>



<p>The <code>scroll()</code> function creates a <em>scroll progress timeline</em> that’s tied to the scroll position of a container, whereas <code>view()</code> creates a <em>view progress timeline</em> that’s based on the visibility of an element within its container.</p>



<p>Both functions are useful in their own ways! I generally think <code>view()</code> is better for item-specific reveal effects. So, for example, if we want to animate a slide <em>only as that specific slide scrolls into the scrollport</em>, then the <code>view()</code> function is the perfect fit. That’s why I’ve focused on it for our carousel example — we want to track an element’s position in the scrollport and run the animation accordingly.</p>


<h3 class="wp-block-heading" id="inset-parameter-and-animation-range-">Inset parameter and <code>animation-range</code></h3>


<p>You might also be wondering what the heck goes in the parentheses of the <code>view()</code> function. It’s a function, after all, so it must accept something in there, right?</p>



<p>CSS <code>view()</code> takes two arguments: <strong>axis</strong> (<code>block</code>, <code>inline</code>, <code>x</code>, and <code>y</code>) and the <strong>inset</strong>. The inset parameter defines an offset from the scrollport&#8217;s edges within which the animated element is tracked. The official syntax looks like this:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">animation-timeline: view(&lt;axis> &lt;view-timeline-inset>);</code></pre>



<p>&#8230;which is merely a fancy way of getting specific with exactly what areas of the scrollport we want to trigger the animation. For some animations, starting and ending the timeline when element fully enters and exits the scrollport may cut things off.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_OPNjXem" src="//codepen.io/anon/embed/OPNjXem?height=550&amp;theme-id=1&amp;slug-hash=OPNjXem&amp;default-tab=result" height="550" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed OPNjXem" title="CodePen Embed OPNjXem" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<figure class="wp-block-image size-large"><img data-recalc-dims="1" fetchpriority="high" decoding="async" width="1024" height="459" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/scroll-animations-range-not-set-1024x459.png?resize=1024%2C459&#038;ssl=1" alt="Two columns of list items. The width of the first item is 100% and each subsequent item in the list gets progressively shorter, creating an effect like a reversed staircase." class="wp-image-390524" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/scroll-animations-range-not-set.png?resize=1024%2C459&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/scroll-animations-range-not-set.png?resize=300%2C134&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/scroll-animations-range-not-set.png?resize=768%2C344&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/scroll-animations-range-not-set.png?resize=1536%2C688&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/scroll-animations-range-not-set.png?w=1982&amp;ssl=1 1982w" sizes="(min-width: 735px) 864px, 96vw" /></figure>



<p>That’s no good! We want each item to fully slide in when it fully enters the scrollport, not when it fully exits. That’s why all the items look so staggered — they’re all at different points in the view timeline.</p>



<p>That’s where the inset parameter makes a big difference. We can be more specific about saying we want each element to start animation when it comes up from the bottom of the scrollport.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">animation: slide-in linear both;
animation-timeline: view(100% 0%);</code></pre>



<p>Ah, much much better:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_MYyvjWP" src="//codepen.io/anon/embed/MYyvjWP?height=550&amp;theme-id=1&amp;slug-hash=MYyvjWP&amp;default-tab=result" height="550" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed MYyvjWP" title="CodePen Embed MYyvjWP" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<figure class="wp-block-video"><video height="886" style="aspect-ratio: 1974 / 886;" width="1974" controls src="https://css-tricks.com/wp-content/uploads/2025/11/scroll-animations-view-slide-in.mov" playsinline></video></figure>



<p>The <a href="https://css-tricks.com/unleash-the-power-of-scroll-driven-animations/#aa-timeline-ranges-demystified"><code>animation-range</code></a> property works along similar lines.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">animation-range: entry; /* same as: entry 0 entry 100%; */</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_GgZvjwQ" src="//codepen.io/anon/embed/GgZvjwQ?height=550&amp;theme-id=1&amp;slug-hash=GgZvjwQ&amp;default-tab=result" height="550" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed GgZvjwQ" title="CodePen Embed GgZvjwQ" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>The <code>animation-range</code> property accepts a slew of other keywords, including <code>exit</code> (when the element leaves the scrollport), <code>cover</code> (when the element begins to enter begins to leave the scrollport), and <code>contain</code> (when the element fully enters then fully leaves the scrollport), among others. <a href="https://css-tricks.com/unleash-the-power-of-scroll-driven-animations/#aa-timeline-ranges-demystified">Geoff has published a bunch of notes and examples</a> looking specifically at each one.</p>


<h3 class="wp-block-heading" id="one-last-carousel-example">One last carousel example</h3>


<p>Generally, carousels use effects like fade in-and-out, scaling, and parallax. However, since most CSS properties are animate-able, and even those who aren’t can be tricked into being so using registered CSS properties (like in the case of gradient lines), you have the option to explore more creative ways of using <code>view()</code> for carousels.</p>



<p>Here’s an example where an animation of just the background position creates a nice movement in a carousel.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_JoXbNbg" src="//codepen.io/anon/embed/preview/JoXbNbg?height=450&amp;theme-id=1&amp;slug-hash=JoXbNbg&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed JoXbNbg" title="CodePen Embed JoXbNbg" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<figure class="wp-block-video"><video height="886" style="aspect-ratio: 1400 / 886;" width="1400" controls src="https://css-tricks.com/wp-content/uploads/2025/11/scroll-animation-carousel-parallax.mov" playsinline></video></figure>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/creating-scroll-based-animations-in-full-view/">Creating Scroll-Based Animations in Full view()</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


The CSS animation-timeline property accepts a view() function which, in turn, returns a timeline of how much of an element is visible in the part of a scroll container that’s viewable (formally known as a scrollport). In other words, rather than letting an animation run a linear progression based on how much time has elapsed, view() runs animations based on the visibility of the animated element within a scrollport.
I like to equate it as the CSS version of JavaScript’s Intersection Observer. We can run an animation on an element as that element enters and exits the scrollport.




Here’s an example:
CodePen Embed Fallback




Pretty neat, right? Depending on where an image is in the scrollable carousel, it goes from small and blurry at the far sides while getting larger and clearer when it hits the center. We have a little scroll snapping in there as well to make sure each image item makes a stop.
It’s not that hard to do! I’ll show you how it’s really the same old animation you’re used to writing in CSS, only applied on a view timeline instead of a normal timeline.
But first, the general layout
All I’m making here is an element I’m calling .carousel:
<main class="carousel">
  
</main>
The elements in .carousel will lay out in a single row, which is a one-liner with flexbox. We’ll also make sure that any content overflowing its space is scrollable:
.carousel {
  display: flex;
  width: max(480px, 50vw);
  overflow-x: auto;
}
And, of course, we need items in it that we can scroll around. A set of image slides.
<main class="carousel">
  <div class="carousel-slide">
    
  </div>
  <div class="carousel-slide">
      <img src="image-1.jpeg" alt="alt text for image 1">
  </div>
  <div class="carousel-slide">
      <img src="image-2.jpeg" alt="alt text for image 2">
  </div>
  
  <div class="carousel-slide">
    
  </div>
</main>
As far as styling those items, each one will be one-third the size of the available space so that we see three items at a time when scrolling:
.carousel {
  /* same as before */

  .carousel-slide {
    flex-shrink: 0;
    width: calc(100% / 3); /* show three at a time */
    aspect-ratio: .8;
    img {
      width: 100%;
    }
  }
}
Then the scrolling
We’ve already set overflow-x on the .carousel, officially making it our scroll container. We can drop in a little scroll snapping to make sure we’re only scrolling one item at a time.
.carousel {
  /* same as before */

  scroll-snap-type: x mandatory;
  scroll-behavior: smooth; /* optional for smooth scrolling */
  scrollbar-width: none; /* optional to hide the scrollbar */
}
We want to make sure that the slides are aligned to the center of the scroll container when snapping into place:
.carousel-slide {
  /* etc. */
  scroll-snap-align: center;
}
Here’s what we have so far:
CodePen Embed Fallback
Next, the animation
Here’s the really cool thing I mentioned at the very start: a view timeline animation is really the same thing as any other CSS animation you write with keyframes. In this case, we want keyframes where the carousel items are small and blurry at the start and end, but become larger and clearer right smack dab in the middle of the animation.
@keyframes slide {
  /* from start to 45%, and to the end (100%) */
  45%, 100% {
    transform: scale(0.5);
    border-radius: 20px;
    filter: blur(6px) brightness(.8);
  }
  /* middle */
  50% {
    transform: scale(1);
    border-radius: 4px;
    filter: none;
  }
}
Looks familiar, right? This is the sort of CSS you’ve been writing forever! And guess what? We set the animation on the element we’re animating just as you normally would as well:
.carousel-slide {
  /* etc. */
  animation: slide; 
}
The only difference is that we want the animation to run on a timeline based on the element’s current view() instead of the regular timeline. That’s where the animation-timeline property comes into play:
.carousel-slide {
  /* etc. */
  animation: slide; 
  animation-timeline: view(inline);
}
Now, technically speaking, we could slap that timeline directly in the animation shorthand property like any other constituent animation property, e.g., animation-name, animation-delay, animation-duration, etc. But assigning a timeline function this way is not supported by any browsers yet. So, for now, your best bet is to declare it on its own. Just be sure to declare it after the animation shorthand, or else you may find yourself inadvertently overriding your view timeline with auto (the default property value) instead of view().
That completes our demo:
CodePen Embed Fallback




See that? All we’ve really done is set a CSS animation that runs on elements. However, instead of running on the default timeline, the animation runs when an element scrolls in and out of view. That’s the difference between standard and view timelines.
view() vs. scroll()
But wait! You may or may not know that view() timelines are part of a larger feature set called CSS Scroll-Driven Animations. And view() is not the only function supported by the animation-timeline property. We also have the scroll() function.
The scroll() function creates a scroll progress timeline that’s tied to the scroll position of a container, whereas view() creates a view progress timeline that’s based on the visibility of an element within its container.
Both functions are useful in their own ways! I generally think view() is better for item-specific reveal effects. So, for example, if we want to animate a slide only as that specific slide scrolls into the scrollport, then the view() function is the perfect fit. That’s why I’ve focused on it for our carousel example — we want to track an element’s position in the scrollport and run the animation accordingly.
Inset parameter and animation-range
You might also be wondering what the heck goes in the parentheses of the view() function. It’s a function, after all, so it must accept something in there, right?
CSS view() takes two arguments: axis (block, inline, x, and y) and the inset. The inset parameter defines an offset from the scrollport’s edges within which the animated element is tracked. The official syntax looks like this:
animation-timeline: view(<axis> <view-timeline-inset>);
…which is merely a fancy way of getting specific with exactly what areas of the scrollport we want to trigger the animation. For some animations, starting and ending the timeline when element fully enters and exits the scrollport may cut things off.
CodePen Embed Fallback




That’s no good! We want each item to fully slide in when it fully enters the scrollport, not when it fully exits. That’s why all the items look so staggered — they’re all at different points in the view timeline.
That’s where the inset parameter makes a big difference. We can be more specific about saying we want each element to start animation when it comes up from the bottom of the scrollport.
animation: slide-in linear both;
animation-timeline: view(100% 0%);
Ah, much much better:
CodePen Embed Fallback




The animation-range property works along similar lines.
animation-range: entry; /* same as: entry 0 entry 100%; */
CodePen Embed Fallback
The animation-range property accepts a slew of other keywords, including exit (when the element leaves the scrollport), cover (when the element begins to enter begins to leave the scrollport), and contain (when the element fully enters then fully leaves the scrollport), among others. Geoff has published a bunch of notes and examples looking specifically at each one.
One last carousel example
Generally, carousels use effects like fade in-and-out, scaling, and parallax. However, since most CSS properties are animate-able, and even those who aren’t can be tricked into being so using registered CSS properties (like in the case of gradient lines), you have the option to explore more creative ways of using view() for carousels.
Here’s an example where an animation of just the background position creates a nice movement in a carousel.
CodePen Embed Fallback


Creating Scroll-Based Animations in Full view() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

It’s not that hard to do! Preethi shows you how it's really the same old animation you’re used to writing in CSS, only applied on a view timeline instead of a normal timeline.
Creating Scroll-Based Animations in Full view() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Creating Scroll-Based Animations in Full view()

<p>The Chrome Dev Team recaps the new CSS features that shipped in Google Chrome this past year in one amazingly designed webpage. They cover new functionality for creating more <a href="https://chrome.dev/css-wrapped-2025/#customizable-components" rel="noopener">customizable components</a>, <a href="https://chrome.dev/css-wrapped-2025/#next-gen-interactions" rel="noopener">next-gen interactions</a>, and <a href="https://chrome.dev/css-wrapped-2025/#optimized-ergonomics" rel="noopener">optimizing ergonomics</a>.</p>
<p>We&#8217;ve &#8230;</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/css-wrapped-2025/">CSS Wrapped 2025</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>The Chrome Dev Team recaps the new CSS features that shipped in Google Chrome this past year in one amazingly designed webpage. They cover new functionality for creating more <a href="https://chrome.dev/css-wrapped-2025/#customizable-components" rel="noopener">customizable components</a>, <a href="https://chrome.dev/css-wrapped-2025/#next-gen-interactions" rel="noopener">next-gen interactions</a>, and <a href="https://chrome.dev/css-wrapped-2025/#optimized-ergonomics" rel="noopener">optimizing ergonomics</a>.</p>



<span id="more-390785"></span>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe title="Explore CSS Wrapped 2025" width="500" height="281" src="https://www.youtube.com/embed/rnT1XBZWHMk?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p>We&#8217;ve been tracking many of these features as well:</p>



<ul class="wp-block-list">
<li>The <a href="https://css-tricks.com/a-first-look-at-the-interest-invoker-api-for-hover-triggered-popovers/">Interest Invoker API</a> and <a href="https://css-tricks.com/invoker-commands-additional-ways-to-work-with-dialog-popover-and-more/">Invoker Commands</a> enable us to work with dialog and popover elements directly in our markup without having to reach for JavaScript.</li>



<li>We are able to tell more interesting stories using <a href="https://css-tricks.com/scrollytelling-on-steroids-with-scroll-state-queries/">scroll state queries</a>.</li>



<li>Juan has been <a href="https://css-tricks.com/how-to-wait-for-the-sibling-count-and-sibling-index-functions/">looking forward</a> to the <code><a href="https://css-tricks.com/almanac/functions/s/sibling-count/">sibling-count()</a></code> and <code><a href="https://css-tricks.com/almanac/functions/s/sibling-index/">sibling-index()</a></code> functions, both of which have been implemented.</li>



<li>The <code><a href="https://css-tricks.com/almanac/functions/a/attr/">attr()</a></code> CSS function was enhanced, it actually does what you&#8217;d expect now!</li>



<li>We have a new way to <a href="https://css-tricks.com/if-css-gets-inline-conditionals/">conditionally adjust properties</a> using the <code>if()</code> function.</li>



<li>Designing interesting looking elements is a bit easier now thanks to <a href="https://css-tricks.com/css-shape-commands/"><code>shape()</code> commands</a>.</li>



<li>Similarly, we have a lot more control over element corners with <code><a href="https://css-tricks.com/what-can-we-actually-do-with-corner-shape/">corner-shape()</a></code>, not just <code>border-radius</code> anymore.</li>



<li>And If all these new functions weren&#8217;t enough, we are able to create our own <a href="https://css-tricks.com/functions-in-css/">custom CSS functions</a>! </li>
</ul>



<p>This is just scratching the surface though, check out the full CSS Wrapped 2025 to see what all made it into the Chrome browser in 2025. It&#8217;s been a wild year for CSS and the CSS Wrapped 2025 page itself demonstrates that in spades.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/css-wrapped-2025/">CSS Wrapped 2025</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


The Chrome Dev Team recaps the new CSS features that shipped in Google Chrome this past year in one amazingly designed webpage. They cover new functionality for creating more customizable components, next-gen interactions, and optimizing ergonomics.










We’ve been tracking many of these features as well:
The Interest Invoker API and Invoker Commands enable us to work with dialog and popover elements directly in our markup without having to reach for JavaScript.
We are able to tell more interesting stories using scroll state queries.
Juan has been looking forward to the sibling-count() and sibling-index() functions, both of which have been implemented.
The attr() CSS function was enhanced, it actually does what you’d expect now!
We have a new way to conditionally adjust properties using the if() function.
Designing interesting looking elements is a bit easier now thanks to shape() commands.
Similarly, we have a lot more control over element corners with corner-shape(), not just border-radius anymore.
And If all these new functions weren’t enough, we are able to create our own custom CSS functions! 
This is just scratching the surface though, check out the full CSS Wrapped 2025 to see what all made it into the Chrome browser in 2025. It’s been a wild year for CSS and the CSS Wrapped 2025 page itself demonstrates that in spades.
CSS Wrapped 2025 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The Chrome Dev Team recaps the new CSS features that shipped in Google Chrome this past year in one amazingly designed webpage. They cover new functionality for creating more customizable components, next-gen interactions, and optimizing ergonomics.
We’ve …
CSS Wrapped 2025 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

CSS Wrapped 2025

<p>The Chrome team recently prototyped a working solution for fitting text to the width of a container in CSS using a <code>text-grow</code> property.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/fit-width-text-in-1-line-of-css/">Fit width text in 1 line of CSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p><a href="https://nerdy.dev/css-text-grow" rel="noopener">From Adam</a>, prototyped in Chrome Canary 145:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">h1 {
  text-grow: per-line scale;
}</code></pre>



<span id="more-390777"></span>



<figure class="wp-block-video"><video height="924" style="aspect-ratio: 1480 / 924;" width="1480" controls src="https://css-tricks.com/wp-content/uploads/2025/12/text-grow.mov" playsinline></video></figure>



<p><a href="https://css-tricks.com/setting-line-length-in-css-and-fitting-text-to-a-container/#aa-watch-for-new-text-grow-text-shrink-properties">Danny discussed this</a> a while back when looking at different approaches for fitting text to a container, spelling out the syntax (<code>text-shrink</code> included) that you can find in <a href="https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md" rel="noopener">Roma Komarov&#8217;s explainer</a>:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">text-grow: &lt;fit-target> &lt;fit-method>? &lt;length>?;
text-shrink: &lt;fit-target> &lt;fit-method>? &lt;length>?;</code></pre>



<ul class="wp-block-list">
<li><strong><code>&lt;fit-target&gt;</code></strong>
<ul class="wp-block-list">
<li><code>per-line</code>: For&nbsp;<code>text-grow</code>, lines of text shorter than the container will grow to fit it. For&nbsp;<code>text-shrink</code>, lines of text&nbsp;<em>longer</em>&nbsp;than the container will&nbsp;<em>shrink</em>&nbsp;to fit it.</li>



<li><code>consistent</code>: For&nbsp;<code>text-grow</code>, the shortest line will grow to fit the container while all other lines grow by the same scaling factor. For&nbsp;<code>text-shrink</code>, the&nbsp;<em>longest</em>&nbsp;line will&nbsp;<em>shrink</em>&nbsp;to fit the container while all other lines shrink by the same scaling factor.</li>
</ul>
</li>



<li><strong><code>&lt;fit-method&gt;</code></strong>&nbsp;(optional)
<ul class="wp-block-list">
<li><code>scale</code>: Scale the glyphs instead of changing the&nbsp;<code>font-size</code>.</li>



<li><code>scale-inline</code>: Scale the glyphs instead of changing the&nbsp;<code>font-size</code>, but only horizontally.</li>



<li><code>font-size</code>: Grow or shrink the font size accordingly.</li>



<li><code>letter-spacing</code>: The letter spacing will grow/shrink instead of the&nbsp;<code>font-size</code>.</li>
</ul>
</li>



<li><strong><code>&lt;length&gt;</code></strong>&nbsp;(optional): The maximum font size for&nbsp;<code>text-grow</code>&nbsp;or minimum font size for&nbsp;<code>text-shrink</code>.</li>
</ul>



<p>Notice the different fit methods — they either scale the glyphs or adjust the text&#8217;s actual <code>font-size</code>. So, naturally, the explainer <a href="https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md#detailed-design-discussion" rel="noopener">notes</a> that accessibility concerns are still being worked out. Like:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>If an end-user tries to enlarge font size, UAs should not fit enlarged lines to the container width. Is minimum-font setting enough?</p>
</blockquote>



<p>Speaking of open questions, <a href="https://bsky.app/profile/una.im/post/3m7azmmmnes2k" rel="noopener">Una Kravets highlights a few on Bluesky</a>:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<ul class="wp-block-list">
<li>Should the last line of a paragraph be scaled?</li>



<li>Is the current line-height behavior as expected?</li>



<li>Should it scale non-text parts such as inline images together?</li>
</ul>
</blockquote>



<p>You can <a href="https://github.com/w3c/csswg-drafts/issues/2528" rel="noopener">contribute to the discussion</a> in the GitHub issue, of course.</p>



<p><a href="https://blog.damato.design/posts/fit-text-responsibly/" rel="noopener">Donnie D’Amato wonders</a> if, perhaps, this idea is better suited for print styles rather than screens. That&#8217;s an excellent use case I hadn&#8217;t thought of.</p>



<p>We sure have come a long way from <a href="https://css-tricks.com/fitting-text-to-a-container/">the days of magic numbers and FitText.js</a>!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/fit-width-text-in-1-line-of-css/">Fit width text in 1 line of CSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


From Adam, prototyped in Chrome Canary 145:
h1 {
  text-grow: per-line scale;
}








Danny discussed this a while back when looking at different approaches for fitting text to a container, spelling out the syntax (text-shrink included) that you can find in Roma Komarov’s explainer:
text-grow: <fit-target> <fit-method>? <length>?;
text-shrink: <fit-target> <fit-method>? <length>?;
<fit-target>

per-line: For text-grow, lines of text shorter than the container will grow to fit it. For text-shrink, lines of text longer than the container will shrink to fit it.
consistent: For text-grow, the shortest line will grow to fit the container while all other lines grow by the same scaling factor. For text-shrink, the longest line will shrink to fit the container while all other lines shrink by the same scaling factor.
<fit-method> (optional)

scale: Scale the glyphs instead of changing the font-size.
scale-inline: Scale the glyphs instead of changing the font-size, but only horizontally.
font-size: Grow or shrink the font size accordingly.
letter-spacing: The letter spacing will grow/shrink instead of the font-size.
<length> (optional): The maximum font size for text-grow or minimum font size for text-shrink.
Notice the different fit methods — they either scale the glyphs or adjust the text’s actual font-size. So, naturally, the explainer notes that accessibility concerns are still being worked out. Like:
If an end-user tries to enlarge font size, UAs should not fit enlarged lines to the container width. Is minimum-font setting enough?
Speaking of open questions, Una Kravets highlights a few on Bluesky:
Should the last line of a paragraph be scaled?
Is the current line-height behavior as expected?
Should it scale non-text parts such as inline images together?
You can contribute to the discussion in the GitHub issue, of course.
Donnie D’Amato wonders if, perhaps, this idea is better suited for print styles rather than screens. That’s an excellent use case I hadn’t thought of.
We sure have come a long way from the days of magic numbers and FitText.js!
Fit width text in 1 line of CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The Chrome team recently prototyped a working solution for fitting text to the width of a container in CSS using a text-grow property.
Fit width text in 1 line of CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Fit width text in 1 line of CSS

<p>I would like to tell you what I learned from a five-year old child about HTML and CSS. It’s funny how explaining something you do almost naturally teaches you about yourself and what you take for granted.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/that-time-i-tried-explaining-html-and-css-to-my-5-year-old-niece/">That Time I Tried Explaining HTML and CSS to My 5-Year Old Niece</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>I would like to tell you what I learned from a five-year old child about HTML and CSS.</p>



<p>Just when I opened my code editor and browser and began writing basic <a href="https://css-tricks.com/html-boilerplates/">HTML boilerplate</a>, my niece walked in. She is tiny and normally very loud, but was standing quietly next to my desk on this particular day, as if she was looking for something.</p>



<span id="more-390475"></span>



<pre class="wp-block-verse"><strong>Niece:</strong> Wassat? Wassat you typing?<br><strong>Me:</strong> Something for the computer.<br><strong>Niece:</strong> It looks funny. All the little lines.<br><strong>Me:</strong> They are instructions.<br><strong>Niece:</strong> Instwu… inschu… instwushun?<br><strong>Me:</strong> Instructions.</pre>



<p>I paused and remembered a <a href="https://www.quora.com/A-6-year-old-wants-to-make-a-website-I-know-basic-HTML-CSS-but-Im-not-good-at-teaching-How-or-where-should-I-start" rel="noopener">Quora question</a> I stumbled on few days earlier about explaining HTML and CSS to a child. I totally skipped the question — I was just scrolling around at the time — but now with my niece standing next to me, I found myself wishing I’d looked it over.</p>



<p>Here’s how I answered. It’s funny how explaining something you do almost naturally teaches you about yourself and what you take for granted.</p>


<h3 class="wp-block-heading" id="we-re-building-a-house-with-bricks-">We’re building a “house” with “bricks”</h3>


<p>My niece didn&#8217;t seem to care about the actual code I was writing, like the specific HTML tags that littered my code editor. No, she was more concerned with what was happening in the browser.</p>



<pre class="wp-block-verse"><strong>Niece:</strong> Oh. So, this big box is your house?<br><strong>Me:</strong> Kind of, yes.</pre>



<p>At that time the screen was empty, looking more like a vast expanse than a webpage. I love that she saw a big white space and likened it to a house that I was building. Her observation pushed me to explain the most basic part of what I was doing.</p>



<p>I told her the editor is where I place my building blocks — not totally unlike having a place where she keeps her LEGOS together as building materials. She watched quietly while I added a simple heading, a short line of text and a button that did not have any behavior yet.</p>



<p>Her eyes were glued on the screen as I refreshed my browser, a few texts appeared. She jerked her head backward a bit when the screen refreshed and turned from an empty house to something with rendered elements.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_zxqzzvJ" src="//codepen.io/anon/embed/zxqzzvJ?height=450&amp;theme-id=1&amp;slug-hash=zxqzzvJ&amp;default-tab=html,result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed zxqzzvJ" title="CodePen Embed zxqzzvJ" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>She was getting it! No, she couldn’t read the code. But she could see the connection between the house and LEGO pieces that gave it structure.</p>


<h3 class="wp-block-heading" id="the-legos-are-just-bricks-in-the-house">The LEGOS are just bricks in the house</h3>


<p>I explained that HTML is what structures the house, merely stacking bricks on the white screen. It has nothing to do with what those bricks should look like. A heading is a heading, a paragraph is a paragraph, and a button is another kind of brick. The browser follows my instructions for adding the bricks I want to the house.</p>



<p>Trying to explain that to her forced me to slow down. I found myself describing HTML as the vocabulary of the page: it gives names to each piece so the browser can build the document tree behind the scenes. Then the tree becomes the foundation that CSS and JavaScript can later rely on. Without those names, the browser would not know where the different elements should relate to one other. Already, I was finding it tough to describe HTML without getting into the other core languages.</p>



<p>I paused, watching her reaction, and was reminded something. Every polished writing begins as a bare idea and then transforms into an outline — just like a polished interface begins with an outline. Before any colors, space, or layout, all we have is structure.</p>



<p>Explaining this to her made those fundamentals feel important to me again, like when I first realized the importance of having a separation of concerns between HTML, CSS, and JavaScript.</p>



<p>My niece began to stare at my screen for an inordinate amount of time, and the silence felt heavy. Even though the structure was there, the page still looked empty to her and she finally asked why the page looked like that.</p>



<p>She expected something more like a house; something with shapes and rooms. What she saw instead was a plain surface with nothing to hold on to. I pointed out the editor and showed the semantic tags I had written. The <code>&lt;body&gt;</code> acts as a container, I told her. The <code>&lt;header&gt;</code> is sort of like the “roof” of the house and the <code>&lt;footer&gt;</code> like the bottom floor.</p>



<p>I explained to her that those elements behave more like rooms and doorways than decoration. They tell the browser what exists and how one part relates to another one. They do not make anything look good, they “frame” document like you frame a house before putting up doors, walls, paint, and carpet.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_jEqwmgm" src="//codepen.io/anon/embed/jEqwmgm?height=450&amp;theme-id=1&amp;slug-hash=jEqwmgm&amp;default-tab=html,result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed jEqwmgm" title="CodePen Embed jEqwmgm" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="decorating-the-house">Decorating the house</h3>


<p>Once the concept of structure clicked with her, I began adding some very simple CSS rules. I kept it minimal by adding a <code>width</code>, some <code>height</code> and a <code>border</code> to one of the elements. She watched the characters appear in my dark editor with the same focus you would give to a puzzle. Those properties names, curly braces and brackets look nothing like layout instructions to her but rather unfamiliar symbols.</p>



<p>Then came the moment, I had to take a step back again and try to explain CSS to her. I told her what I was typing are also instructions, just like HTML, but instead of instructions for laying bricks, these were instructions for how the bricks should look. For example, I can tell the browser how large a brick should be, where it should sit, and how it should appear.</p>



<p>This is the core of CSS, right? You select a brick and describe to the browser how it looks. Saying it out loud reminded me that <a href="https://geoffgraham.me/css-is-logical/" rel="noopener">CSS is literal and logical</a>.</p>



<p>A width. A height. And a border. That’s all it takes to add a little shape.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_LENWMBQ" src="//codepen.io/anon/embed/LENWMBQ?height=450&amp;theme-id=1&amp;slug-hash=LENWMBQ&amp;default-tab=css,result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed LENWMBQ" title="CodePen Embed LENWMBQ" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>I know there is probably a more “academic” way to teach CSS. For example, <a href="https://rachelandrew.co.uk/archives/2018/10/04/the-way-we-talk-about-css/" rel="noopener">writing modes are probably an excellent starting point</a> to get into directionality and positioning before a single splash of color is on the page. That’s all fine and whatnot, but all of that is gibberish to a five-year old. I can’t even get into things like <code>aspect-ratio</code> without first getting into the basic <code>width</code> and <code>height</code>. Those fancy things can wait for now.</p>



<p>What I was looking for was an <a href="https://css-tricks.com/moment-css-started-making-sense/">“A-ha!” moment</a>. I continued the exercise and drew a little house. Then I refreshed the page and the structure finally had a shape.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_azNwwoa" src="//codepen.io/anon/embed/azNwwoa?height=600&amp;theme-id=1&amp;slug-hash=azNwwoa&amp;default-tab=html,result" height="600" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed azNwwoa" title="CodePen Embed azNwwoa" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>It wasn&#8217;t much, of course: a little triangle that looked like a roof, a square pretending to be a wall, two tiny squares for windows, and a skinny rectangle that I guess could be a door. It looked like something you draw fast with a dull pencil. Regardless, my niece leaned in right away, almost bumping her forehead on the screen.</p>



<pre class="wp-block-verse"><strong>Niece:</strong> Why does the house not have color? It looks so plain.<br><strong>Me:</strong> I haven’t added color yet.<br><strong>Niece:</strong> You forgot. You always forgot.<br><strong>Me:</strong> I’ll add it.</pre>



<p>I added a little color to the house. And that’s when things started to click.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_ZYQvXdM" src="//codepen.io/anon/embed/ZYQvXdM?height=600&amp;theme-id=1&amp;slug-hash=ZYQvXdM&amp;default-tab=css,result" height="600" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed ZYQvXdM" title="CodePen Embed ZYQvXdM" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<pre class="wp-block-verse"><strong>Niece:</strong> So this brick says what is there.<br><strong>Me:</strong> Yes.<br><strong>Niece:</strong> And this color thing make it pretty?<br><strong>Me:</strong> That’s right.<br><strong>Niece:</strong> So HTML says what is there, and CSS makes it pretty.<br><strong>Me:</strong> Exactly.</pre>



<p>That observation presented the perfect opportunity to clarify the separation between the HTML and CSS. HTML describes what exists in the document tree. CSS describes how those elements should appear. Without styling, every element is technically present but visually absent.</p>



<p>“Now it looks <em>real</em>!” she declared. She even pointed to the drawers in the room we were in and related them to the structure of boxes and the decorations that made them look the way they were.</p>



<p>HTML lays down the pieces and CSS brings them to life with lines, colors, and other bits of decoration and positioning. This can still feel magical even to us, right? Getting my niece to this point reminded me why even the basics of what we do is satisfying.</p>


<h3 class="wp-block-heading" id="what-i-learned-from-a-five-year-old">What I learned from a five-year old</h3>


<p>“Now I can do computer, too!” she announced. That’s when my niece decided she was satisfied and bounced out of the room. I kept the little house on my screen for a while longer and thought about the exchange.</p>



<p>It’s easy to get into a rut where the magic of what we do is superseded by other things. We have a job we need to do and we sweep away the “boring” stuff to get things done. And once those things are done, how often do we pause and actually look at what we’re doing, line by line?</p>



<p>That’s the biggest thing I learned from my five-year old niece: there’s still magic in what we do, no matter how big or small the task. We might spend hours in blog posts and social threads getting pedantic about preferred toolsets, specific techniques, what’s considered best practice, and how things should be named. And, yes, these do matter matter. But the brief time I spent with my niece felt more important, meaningful, and satisfying than anything else. Strip everything away and the <a href="https://remysharp.com/2016/01/20/why-i-love-working-with-the-web" rel="noopener">web still runs on something simple</a>.</p>



<p>Those few boxes with color on them capture my attention longer than the assignment I was supposed to be doing. I don’t even know why I kept staring at it. Maybe because I realized I rush through these basics without even noticing. That moment sort of pushed me to slow down and actually look at what I was doing, line by line, instead of jumping straight to the point.</p>



<p>HTML suddenly looks less like code and more like building materials to me. CSS, meanwhile, not only steps in with a paint brush, but has the ability to mold those materials into beautiful shapes like clay.</p>



<p>So, even though my niece came to me to help her understand HTML and CSS, she was actually the one who taught me a thing or two about it. It was the way she looked at the page and saw a house that made things click more succinctly for me than how I’ve heard or read it anywhere else. The way she articulated the relationship between HTML and CSS cut straight to the point in a way nothing else has for me.</p>


<h3 class="wp-block-heading" id="how-would-you-explain-it-">How would you explain it?</h3>


<p>Taking time to explain the basics of HTML and CSS proved to me that teaching what we do — or anything, really — reveals what we know and especially what we assume we know. Teaching someone who has never seen or written a single line of code forces you to check yourself. Apparently, that’s what <a href="https://www.mometrix.com/blog/the-feynman-technique/" rel="noopener">The Feynman Technique</a> for learning is all about: teaching to learn.</p>



<p>Learning is a subjective journey rather than a one-size-fits-all sort of deal. Some of us learn visually, some learn by reading, and others learn through activity. And, naturally, something like age drastically impacts things. Adults come in with way more context and experience than a child, even if that context and experience has nothing to do with writing code. So, while I might have taken a more technical route with an adult, perhaps, finding an analogy that resonates with something my niece relates to was the way more effective path for her, even if it didn’t really require writing code.</p>



<p>Which begs me to ask the question: How would you have approached explaining HTML and CSS to my niece? Or maybe not my niece, but a five-year old in your life that you know? What analogies would you use, if any? I think it would be very cool for you to take time to do exactly that and reflect on exactly what you said. What does that tell you about what you know and assume about your work?</p>


<h3 class="wp-block-heading" id="further-reading">Further reading</h3>


<ul class="wp-block-list">
<li><a href="https://rachelandrew.co.uk/archives/2019/01/30/html-css-and-our-vanishing-industry-entry-points/" rel="noopener">“HTML, CSS and our vanishing industry entry points”</a> (Rachel Andrew)</li>



<li><a href="https://www.smashingmagazine.com/2024/05/in-praise-of-the-basics/" rel="noopener">“In Praise of the Basics”</a> (Geoff Graham)</li>



<li><a href="https://css-tricks.com/learning-to-learn/">“Learning to Learn”</a> (Sarah Drasner)</li>



<li><a href="https://www.quora.com/A-6-year-old-wants-to-make-a-website-I-know-basic-HTML-CSS-but-Im-not-good-at-teaching-How-or-where-should-I-start" rel="noopener">“A 6-year old wants to make a website.”</a> (Quora)</li>
</ul>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/that-time-i-tried-explaining-html-and-css-to-my-5-year-old-niece/">That Time I Tried Explaining HTML and CSS to My 5-Year Old Niece</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


I would like to tell you what I learned from a five-year old child about HTML and CSS.
Just when I opened my code editor and browser and began writing basic HTML boilerplate, my niece walked in. She is tiny and normally very loud, but was standing quietly next to my desk on this particular day, as if she was looking for something.




Niece: Wassat? Wassat you typing?
Me: Something for the computer.
Niece: It looks funny. All the little lines.
Me: They are instructions.
Niece: Instwu… inschu… instwushun?
Me: Instructions.
I paused and remembered a Quora question I stumbled on few days earlier about explaining HTML and CSS to a child. I totally skipped the question — I was just scrolling around at the time — but now with my niece standing next to me, I found myself wishing I’d looked it over.
Here’s how I answered. It’s funny how explaining something you do almost naturally teaches you about yourself and what you take for granted.
We’re building a “house” with “bricks”
My niece didn’t seem to care about the actual code I was writing, like the specific HTML tags that littered my code editor. No, she was more concerned with what was happening in the browser.
Niece: Oh. So, this big box is your house?
Me: Kind of, yes.
At that time the screen was empty, looking more like a vast expanse than a webpage. I love that she saw a big white space and likened it to a house that I was building. Her observation pushed me to explain the most basic part of what I was doing.
I told her the editor is where I place my building blocks — not totally unlike having a place where she keeps her LEGOS together as building materials. She watched quietly while I added a simple heading, a short line of text and a button that did not have any behavior yet.
Her eyes were glued on the screen as I refreshed my browser, a few texts appeared. She jerked her head backward a bit when the screen refreshed and turned from an empty house to something with rendered elements.
CodePen Embed Fallback
She was getting it! No, she couldn’t read the code. But she could see the connection between the house and LEGO pieces that gave it structure.
The LEGOS are just bricks in the house
I explained that HTML is what structures the house, merely stacking bricks on the white screen. It has nothing to do with what those bricks should look like. A heading is a heading, a paragraph is a paragraph, and a button is another kind of brick. The browser follows my instructions for adding the bricks I want to the house.
Trying to explain that to her forced me to slow down. I found myself describing HTML as the vocabulary of the page: it gives names to each piece so the browser can build the document tree behind the scenes. Then the tree becomes the foundation that CSS and JavaScript can later rely on. Without those names, the browser would not know where the different elements should relate to one other. Already, I was finding it tough to describe HTML without getting into the other core languages.
I paused, watching her reaction, and was reminded something. Every polished writing begins as a bare idea and then transforms into an outline — just like a polished interface begins with an outline. Before any colors, space, or layout, all we have is structure.
Explaining this to her made those fundamentals feel important to me again, like when I first realized the importance of having a separation of concerns between HTML, CSS, and JavaScript.
My niece began to stare at my screen for an inordinate amount of time, and the silence felt heavy. Even though the structure was there, the page still looked empty to her and she finally asked why the page looked like that.
She expected something more like a house; something with shapes and rooms. What she saw instead was a plain surface with nothing to hold on to. I pointed out the editor and showed the semantic tags I had written. The <body> acts as a container, I told her. The <header> is sort of like the “roof” of the house and the <footer> like the bottom floor.
I explained to her that those elements behave more like rooms and doorways than decoration. They tell the browser what exists and how one part relates to another one. They do not make anything look good, they “frame” document like you frame a house before putting up doors, walls, paint, and carpet.
CodePen Embed Fallback
Decorating the house
Once the concept of structure clicked with her, I began adding some very simple CSS rules. I kept it minimal by adding a width, some height and a border to one of the elements. She watched the characters appear in my dark editor with the same focus you would give to a puzzle. Those properties names, curly braces and brackets look nothing like layout instructions to her but rather unfamiliar symbols.
Then came the moment, I had to take a step back again and try to explain CSS to her. I told her what I was typing are also instructions, just like HTML, but instead of instructions for laying bricks, these were instructions for how the bricks should look. For example, I can tell the browser how large a brick should be, where it should sit, and how it should appear.
This is the core of CSS, right? You select a brick and describe to the browser how it looks. Saying it out loud reminded me that CSS is literal and logical.
A width. A height. And a border. That’s all it takes to add a little shape.
CodePen Embed Fallback
I know there is probably a more “academic” way to teach CSS. For example, writing modes are probably an excellent starting point to get into directionality and positioning before a single splash of color is on the page. That’s all fine and whatnot, but all of that is gibberish to a five-year old. I can’t even get into things like aspect-ratio without first getting into the basic width and height. Those fancy things can wait for now.
What I was looking for was an “A-ha!” moment. I continued the exercise and drew a little house. Then I refreshed the page and the structure finally had a shape.
CodePen Embed Fallback
It wasn’t much, of course: a little triangle that looked like a roof, a square pretending to be a wall, two tiny squares for windows, and a skinny rectangle that I guess could be a door. It looked like something you draw fast with a dull pencil. Regardless, my niece leaned in right away, almost bumping her forehead on the screen.
Niece: Why does the house not have color? It looks so plain.
Me: I haven’t added color yet.
Niece: You forgot. You always forgot.
Me: I’ll add it.
I added a little color to the house. And that’s when things started to click.
CodePen Embed Fallback
Niece: So this brick says what is there.
Me: Yes.
Niece: And this color thing make it pretty?
Me: That’s right.
Niece: So HTML says what is there, and CSS makes it pretty.
Me: Exactly.
That observation presented the perfect opportunity to clarify the separation between the HTML and CSS. HTML describes what exists in the document tree. CSS describes how those elements should appear. Without styling, every element is technically present but visually absent.
“Now it looks real!” she declared. She even pointed to the drawers in the room we were in and related them to the structure of boxes and the decorations that made them look the way they were.
HTML lays down the pieces and CSS brings them to life with lines, colors, and other bits of decoration and positioning. This can still feel magical even to us, right? Getting my niece to this point reminded me why even the basics of what we do is satisfying.
What I learned from a five-year old
“Now I can do computer, too!” she announced. That’s when my niece decided she was satisfied and bounced out of the room. I kept the little house on my screen for a while longer and thought about the exchange.
It’s easy to get into a rut where the magic of what we do is superseded by other things. We have a job we need to do and we sweep away the “boring” stuff to get things done. And once those things are done, how often do we pause and actually look at what we’re doing, line by line?
That’s the biggest thing I learned from my five-year old niece: there’s still magic in what we do, no matter how big or small the task. We might spend hours in blog posts and social threads getting pedantic about preferred toolsets, specific techniques, what’s considered best practice, and how things should be named. And, yes, these do matter matter. But the brief time I spent with my niece felt more important, meaningful, and satisfying than anything else. Strip everything away and the web still runs on something simple.
Those few boxes with color on them capture my attention longer than the assignment I was supposed to be doing. I don’t even know why I kept staring at it. Maybe because I realized I rush through these basics without even noticing. That moment sort of pushed me to slow down and actually look at what I was doing, line by line, instead of jumping straight to the point.
HTML suddenly looks less like code and more like building materials to me. CSS, meanwhile, not only steps in with a paint brush, but has the ability to mold those materials into beautiful shapes like clay.
So, even though my niece came to me to help her understand HTML and CSS, she was actually the one who taught me a thing or two about it. It was the way she looked at the page and saw a house that made things click more succinctly for me than how I’ve heard or read it anywhere else. The way she articulated the relationship between HTML and CSS cut straight to the point in a way nothing else has for me.
How would you explain it?
Taking time to explain the basics of HTML and CSS proved to me that teaching what we do — or anything, really — reveals what we know and especially what we assume we know. Teaching someone who has never seen or written a single line of code forces you to check yourself. Apparently, that’s what The Feynman Technique for learning is all about: teaching to learn.
Learning is a subjective journey rather than a one-size-fits-all sort of deal. Some of us learn visually, some learn by reading, and others learn through activity. And, naturally, something like age drastically impacts things. Adults come in with way more context and experience than a child, even if that context and experience has nothing to do with writing code. So, while I might have taken a more technical route with an adult, perhaps, finding an analogy that resonates with something my niece relates to was the way more effective path for her, even if it didn’t really require writing code.
Which begs me to ask the question: How would you have approached explaining HTML and CSS to my niece? Or maybe not my niece, but a five-year old in your life that you know? What analogies would you use, if any? I think it would be very cool for you to take time to do exactly that and reflect on exactly what you said. What does that tell you about what you know and assume about your work?
Further reading
“HTML, CSS and our vanishing industry entry points” (Rachel Andrew)
“In Praise of the Basics” (Geoff Graham)
“Learning to Learn” (Sarah Drasner)
“A 6-year old wants to make a website.” (Quora)
That Time I Tried Explaining HTML and CSS to My 5-Year Old Niece originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I would like to tell you what I learned from a five-year old child about HTML and CSS. It’s funny how explaining something you do almost naturally teaches you about yourself and what you take for granted.
That Time I Tried Explaining HTML and CSS to My 5-Year Old Niece originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

That Time I Tried Explaining HTML and CSS to My 5-Year Old Niece

<p>It's easy to think of HTML Web Components as a recent feature, but it has roots that go all the way back to 1998.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/html-web-components-proposal-from-1998/">HTML Web Components Proposal From 1998</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>Web components, as imagined in 1998 <a href="https://www.w3.org/TR/NOTE-HTMLComponents" rel="noopener">from a never-adopted specification</a>:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Componentization is a powerful paradigm that allows component users to build applications using &#8216;building blocks&#8217; of functionality without having to implement those building blocks themselves, or necessarily understand how the building works in fine detail. This method makes building complex applications easier by breaking them down into more manageable chunks and allowing the building blocks to be reused in other applications. </p>
</blockquote>



<span id="more-390691"></span>



<p>I still think of web components as a recent feature. The first time we even took a stab at explaining them here at CSS-Tricks was in a <a href="https://css-tricks.com/an-introduction-to-web-components/">five-part series by Caleb Williams back in 2019</a>. John Rhea followed that up with another <a href="https://css-tricks.com/web-components-are-easier-than-you-think/">six-part series in 2021</a>. Not that long ago.</p>



<p>But nay! Jay Hoffman dug up the 1998 proposal cited above and shared it with me <a href="https://www.youtube.com/watch?v=GJlhzxVftCk&amp;list=PL_BRVuWxk8sr7N-e2JT5R2fDcKLvK8WIC&amp;index=1" rel="noopener">from a recent Igalia Chat</a> (which is a <a href="https://www.youtube.com/playlist?list=PL_BRVuWxk8sr7N-e2JT5R2fDcKLvK8WIC" rel="noopener">great podcast</a>, by the way) he had with Brian Kardell, Eric Meyer, and Jeremy Keith.</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="Web Backstories: Shadow DOM" width="500" height="281" src="https://www.youtube.com/embed/GJlhzxVftCk?list=PL_BRVuWxk8sr7N-e2JT5R2fDcKLvK8WIC" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p>So, we&#8217;re really talking about a feature that&#8217;s been in the works for nearly <em>30 years</em>. Style encapsulation is firmly a part of the time capsule that is web history.</p>



<p>It&#8217;s not that we need to know any of this information today, but the context is what&#8217;s key. It&#8217;s easy to overlook the early work put into something, especially when it comes to the web which is littered with arcane artifacts in disparate places.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/html-web-components-proposal-from-1998/">HTML Web Components Proposal From 1998</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Web components, as imagined in 1998 from a never-adopted specification:
Componentization is a powerful paradigm that allows component users to build applications using ‘building blocks’ of functionality without having to implement those building blocks themselves, or necessarily understand how the building works in fine detail. This method makes building complex applications easier by breaking them down into more manageable chunks and allowing the building blocks to be reused in other applications. 




I still think of web components as a recent feature. The first time we even took a stab at explaining them here at CSS-Tricks was in a five-part series by Caleb Williams back in 2019. John Rhea followed that up with another six-part series in 2021. Not that long ago.
But nay! Jay Hoffman dug up the 1998 proposal cited above and shared it with me from a recent Igalia Chat (which is a great podcast, by the way) he had with Brian Kardell, Eric Meyer, and Jeremy Keith.






So, we’re really talking about a feature that’s been in the works for nearly 30 years. Style encapsulation is firmly a part of the time capsule that is web history.
It’s not that we need to know any of this information today, but the context is what’s key. It’s easy to overlook the early work put into something, especially when it comes to the web which is littered with arcane artifacts in disparate places.
HTML Web Components Proposal From 1998 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

It's easy to think of HTML Web Components as a recent feature, but it has roots that go all the way back to 1998.
HTML Web Components Proposal From 1998 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

HTML Web Components Proposal From 1998

<p>A good measure makes reading text comfortable, while a bad one makes it more difficult. So, rather than allowing layout to dictate the measure, doesn’t it make more sense for the measure to inform layout decisions?</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/getting-creative-with-the-measure/">Getting Creative With “The Measure”</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


I spend an unhealthy amount of time on the typography in my designs, and if you’ve read any traditional typography books, you might remember “the measure.” If not, it’s simply the length of a line of text. But measure means more than that, and once you understand what it represents, it can change how you think about layout entirely.
But why’s it called the measure?




Photo: Wilhei, via Wikipedia (CC BY 3.0)



Before desktop publishing, typesetters worked with physical metal type. They set lines of text within a composing stick, and the width of the stick was called the measure. It was literally the space you could fit type into, and everything else on the page — from column widths to margins and gutters — was designed around it.
A good measure makes reading text comfortable, while a bad one makes it more difficult.
An uncomfortable measure makes reading more difficult. See this example in my lab.



And when the measure is correct, the rest of the layout falls into place. So, rather than allowing layout to dictate the measure, doesn’t it make more sense for the measure to inform layout decisions?
Turning the measure into a custom property
In my CSS, I start by defining a custom property:
:root {
  --measure: 60ch;
}
ch units are ideal for this because they relate to the width of the zero (0) character in a chosen font. Somewhere between 60–70 characters per line is a comfortable reading length, so 65 characters feels natural.
60ch is a solid starting point, but it isn’t universal. Different typefaces produce different real-world line lengths, even when the character count stays the same. Typefaces with a large x-height appear visually larger, so 60ch can feel longer than it really is. Condensed faces make 60ch feel too short. Wider faces can make it feel too long. Even small tracking changes stretch or compress the perceived measure.
The point is simple: treat 60ch as a baseline, then adjust by eye. Once the measure becomes a variable, you can use it across your layout to keep everything connected.
Keeping text readable
I suspect most developers have used the max-width property. Although it took time to retrain my muscle memory, I now use CSS logical properties, replacing max-width with max-inline-size:
article {
  max-inline-size: var(--measure);
  margin-inline: auto;
}
Well considered measure makes reading more comfortable. See this example in my lab.



That prevents long-line syndrome, which afflicts too many websites when viewed on large screens.
Designing multi-column text
Multi-column layout is one of the most underrated CSS layout tools. Instead of specifying the number of columns, defining the column width lets the browser decide how many columns fit along the inline axis. The measure can also define the widths of those columns:
article {
  column-width: var(--measure);
}
The measure can define multi columns widths. See this example in my lab.



When the columns’ parent container becomes wide enough, a browser flows text into as many readable columns as will fit. When there’s not enough space for multiple columns, the layout falls back to a single column, all without breakpoints and media queries.
Letting the measure influence a grid
The measure also helps me design grids which feel connected to my content. For example, when I’m implementing a layout with a column containing long-form content, plus another flexible column, I can lock the text content to the measure:
.layout {
  display: grid;
  grid-template-columns: minmax(0, var(--measure)) 1fr;
}
The measure also creates grids which feel connected to content. See this example in my lab.



That first column ensures that reading text remains comfortable, while the second adjusts to whatever horizontal space remains.
Measure-driven container queries
For years, developers learned to think of screen sizes in terms of specific breakpoints (320px, 48em, 64em, and so on) and media queries. It’s a hard habit to break and one which, to be honest, I haven’t always managed myself.
Those numbers don’t come from content; devices define them. They really should be called “guesspoints” because we mostly never know which numbers work for most people. Instead of dictating that a layout switches at, say, 48em and 64em, I can let my content decide when a layout should change by using the measure.




Measure makes a better breakpoint. A measure-driven breakpoint, combined with container queries, responds to text content. So, when a column becomes narrower than a readable line length, a layout can collapse. But when it becomes wide enough to support more structure, the layout can expand.
A CSS container query checks the width of the component’s container instead of a screen or the viewport. For instance, when a component is narrower than 65 characters, I can apply specific styles:
/* When the container is no wider than the --measure */
@container (max-width: var(--measure)) {
  /* Styles */
}
My design might include multiple columns, perhaps a wider column for the main content and a narrower one for supporting information:
[data-layout="yogi"] {
  display: grid;
  grid-template-columns: 3fr 1fr;
}
If the container can’t support a text column equal to the measure, this query replaces the two columns with a single column layout:
@container (max-width: var(--measure)) {
  [data-layout="yogi"] {
    grid-template-columns: 1fr;
  }
}
This feels more natural because the composition is connected to the content rather than the device’s width, creating a comfortable reading environment.
Making a measure system
Depending on the variety of content I need to present, on certain projects, I define several variations of the measure:
:root {
  --measure: 60ch;
  --measure-s: 55ch;
  --measure-l: 80ch;
}
This gives me a variety of line lengths for use in different situations:
Small for captions and other shorter text blocks
Regular for body copy
Large for introductions, headings, and hero sections
When type, spacing, and layout all share the same underlying rhythm, the result can feel more coherent and more intentional.
Considering the measure can change how you design
When you design with the measure in mind, layout stops being guesswork and becomes a conversation between content and composition. Reading becomes more comfortable, and the page feels more deliberate. It’s a small shift, but once you start anchoring your design decisions to the measure, it changes how you approach layout entirely.
Further reading
dialog    
    
  
    
      Andy Clarke    
  
images UI/IX Design    
    
  
    
      Andy Clarke    
  
inspiration typography    
    
  
    
      Andy Clarke    
  
rwd UI/IX Design    
    
  
    
      Andy Clarke    
  
initial-letter inspiration typography    
    
  
    
      Andy Clarke    
  
css shapes images UI/IX Design    
    
  
    
      Andy Clarke    
  
Getting Creative With “The Measure” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A good measure makes reading text comfortable, while a bad one makes it more difficult. So, rather than allowing layout to dictate the measure, doesn’t it make more sense for the measure to inform layout decisions?
Getting Creative With “The Measure” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Getting Creative With “The Measure”

<p>Unconvinced of the value of scrollytelling? Alright, skeptic, let’s first warm up with some common use cases for scroll-based styling.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/scrollytelling-on-steroids-with-scroll-state-queries/">Scrollytelling on Steroids With Scroll-State Queries</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Unconvinced of the value of scrollytelling? Alright, skeptic, let’s first warm up with some common use cases for scroll-based styling.
Scrollytelling on Steroids With Scroll-State Queries originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Scrollytelling on Steroids With Scroll-State Queries

<p><a href="https://www.bram.us/2025/11/25/use-overscroll-behavior-contain-to-prevent-a-page-from-scrolling-while-a-dialog-is-open/" rel="noopener">Bramus</a>:</p>
<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Chrome 144 features a small change to <code>overscroll-behavior</code>: it now also works on non-scrollable scroll containers. While this change might seem trivial, it fixes an issue developers have been dealing with for ages: prevent a page from </p>
</blockquote>
<p>&#8230;</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/prevent-a-page-from-scrolling-while-a-dialog-is-open/">Prevent a page from scrolling while a dialog is open</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p><a href="https://www.bram.us/2025/11/25/use-overscroll-behavior-contain-to-prevent-a-page-from-scrolling-while-a-dialog-is-open/" rel="noopener">Bramus</a>:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Chrome 144 features a small change to <code>overscroll-behavior</code>: it now also works on non-scrollable scroll containers. While this change might seem trivial, it fixes an issue developers have been dealing with for ages: prevent a page from scrolling while a <em>(modal)</em> <code>&lt;dialog></code> is open.</p>
</blockquote>



<span id="more-390613"></span>



<p>YES! Way back in 2019, I worked on <a href="https://css-tricks.com/prevent-page-scrolling-when-a-modal-is-open/">&#8220;Prevent Page Scrolling When a Modal is Open&#8221;</a> with Brad Wu about this exact thing. Apparently this was mere months before <a href="https://css-tricks.com/some-hands-on-with-the-html-dialog-element/">we got our hands on the true HTML <code>&lt;dialog></code> element</a>. In any case, you can see the trouble with active scrolling when a &#8220;dialog&#8221; is open:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_KLGKqJ" src="//codepen.io/anon/embed/KLGKqJ?height=450&amp;theme-id=1&amp;slug-hash=KLGKqJ&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed KLGKqJ" title="CodePen Embed KLGKqJ" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>The problem is that the dialog itself is not a scroll container. If it was, we could slap <code>overscroll-behavior: contain</code> on it and be done with it. Brad demoed his solution  that involved a JavaScript-y approach that sets the <code>&lt;body></code> to fixed positioning when the dialog is in an open state:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_LogERe" src="//codepen.io/anon/embed/LogERe?height=450&amp;theme-id=1&amp;slug-hash=LogERe&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed LogERe" title="CodePen Embed LogERe" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>That&#8217;s the tweak Bramus is talking about. In Chrome 144, that&#8217;s no longer the case. Going back to that first demo, we can do a couple of things to avoid all the JS mumbo-jumbo.</p>



<p>First, we declare <code>overscroll-behavior</code> on both the dialog element and the backdrop and set it to <code>contain</code>:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">body {
  overscroll-behavior: contain;
}

#dialog {
  overscroll-behavior: contain;
}</code></pre>



<p>You&#8217;d think that would do it, but there&#8217;s a super key final step. That dialog needs to be a scroll container, which we can do explicitly:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#dialog {
  overscroll-behavior: contain;
  overflow: hidden;
}</code></pre>



<p>Chrome 144 needed, of course:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_WbwzERb" src="//codepen.io/anon/embed/WbwzERb?height=450&amp;theme-id=1&amp;slug-hash=WbwzERb&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed WbwzERb" title="CodePen Embed WbwzERb" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>The demo that Bramus provided is much, much better as it deals with the actual HTML <code>&lt;dialog></code> element and its <code><a href="https://css-tricks.com/almanac/pseudo-selectors/b/backdrop/">::backdrop</a></code>:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_QwNMroY" src="//codepen.io/anon/embed/QwNMroY?height=450&amp;theme-id=1&amp;slug-hash=QwNMroY&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed QwNMroY" title="CodePen Embed QwNMroY" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/prevent-a-page-from-scrolling-while-a-dialog-is-open/">Prevent a page from scrolling while a dialog is open</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Bramus:
Chrome 144 features a small change to overscroll-behavior: it now also works on non-scrollable scroll containers. While this change might seem trivial, it fixes an issue developers have been dealing with for ages: prevent a page from scrolling while a (modal) <dialog> is open.




YES! Way back in 2019, I worked on “Prevent Page Scrolling When a Modal is Open” with Brad Wu about this exact thing. Apparently this was mere months before we got our hands on the true HTML <dialog> element. In any case, you can see the trouble with active scrolling when a “dialog” is open:
CodePen Embed Fallback
The problem is that the dialog itself is not a scroll container. If it was, we could slap overscroll-behavior: contain on it and be done with it. Brad demoed his solution  that involved a JavaScript-y approach that sets the <body> to fixed positioning when the dialog is in an open state:
CodePen Embed Fallback
That’s the tweak Bramus is talking about. In Chrome 144, that’s no longer the case. Going back to that first demo, we can do a couple of things to avoid all the JS mumbo-jumbo.
First, we declare overscroll-behavior on both the dialog element and the backdrop and set it to contain:
body {
  overscroll-behavior: contain;
}

#dialog {
  overscroll-behavior: contain;
}
You’d think that would do it, but there’s a super key final step. That dialog needs to be a scroll container, which we can do explicitly:
#dialog {
  overscroll-behavior: contain;
  overflow: hidden;
}
Chrome 144 needed, of course:
CodePen Embed Fallback
The demo that Bramus provided is much, much better as it deals with the actual HTML <dialog> element and its ::backdrop:
CodePen Embed Fallback
Prevent a page from scrolling while a dialog is open originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Bramus:
Chrome 144 features a small change to overscroll-behavior: it now also works on non-scrollable scroll containers. While this change might seem trivial, it fixes an issue developers have been dealing with for ages: prevent a page from 
…
Prevent a page from scrolling while a dialog is open originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Prevent a page from scrolling while a dialog is open

<p>There are many ways to share properties, but what would it look like to inherit and use <em>any</em> parent property value on a child?</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/on-inheriting-and-sharing-property-values/">On Inheriting and Sharing Property Values</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>Sometimes I want to set the value of a CSS property to that of a different property, even if I don’t know what that value is, and even if it changes later. Unfortunately though, that’s not possible (at least, there isn’t a CSS function that specifically does that).</p>



<span id="more-389944"></span>



<p>In my opinion, it’d be super useful to have something like this (for interpolation, maybe you’d throw <a href="https://css-tricks.com/almanac/functions/c/calc-size/"><code>calc-size()</code></a> in there as well):</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Totally hypothetical */
button {
  border-radius: compute(height, self);
  border-radius: compute(height, inherit);
  border-radius: compute(height, #this);
}</code></pre>



<p>In 2021, <a href="https://discourse.wicg.io/t/css-function-to-reference-other-propertys-value/5593/" rel="noopener">Lea Verou explained</a> why, despite being proposed numerous times, implementing such a general-purpose CSS function like this isn’t feasible. Having said that, I do remain hopeful, because things are always evolving and <a href="https://css-tricks.com/masonry-watching-a-css-feature-evolve/">the CSSWG process isn’t always linear</a>.</p>



<p>In the meantime, even though there isn’t a CSS function that enables us to get the value of a different property, you might be able to achieve your outcome using a different method, and those methods are what we’re going to look at today.</p>


<h3 class="wp-block-heading" id="the-fool-proof-css-custom-properties-method">The fool-proof CSS custom properties method</h3>


<p>We can easily get the value of a different CSS property using custom properties, but we’d need to know what the value is in order to declare the custom property to begin with. This isn’t ideal, but it does enable us to achieve <em>some</em> outcomes.</p>



<p>Let’s jump back to the example from the intro where we try to set the <a href="https://css-tricks.com/almanac/properties/b/border-radius/"><code>border-radius</code></a> based on the <code>height</code>, only this time we know what the height is and we store it as a CSS custom property for reusability, and so we’re able to achieve our outcome:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">button {
  --button-height: 3rem;
  height: var(--button-height);
  border-radius: calc(var(--button-height) * 0.3);
}</code></pre>



<p>We can even place that <code>--button-height</code> custom property higher up in the CSS cascade to make it available to more containment contexts.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">:root {
  /* Declare here to use anywhere */
  --button-height: 3rem;

  header {
    --header-padding: 1rem;
    padding: var(--header-padding);
  
    /* Height is unknown (but we can calculate it) */
    --header-height: calc(var(--button-height) + (var(--header-padding) * 2));
  
    /* Which means we can calculate this, too */
    border-radius: calc(var(--header-height) * 0.3);
  
    button {
      /* As well as these, of course */
      height: var(--button-height);
      border-radius: calc(var(--button-height) * 0.3);

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



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_jEWadeY" src="//codepen.io/anon/embed/jEWadeY?height=450&amp;theme-id=1&amp;slug-hash=jEWadeY&amp;default-tab=css,result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed jEWadeY" title="CodePen Embed jEWadeY" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>I guess when my math teacher said that I’d need algebra one day. She wasn’t lying!</p>


<h3 class="wp-block-heading" id="the-unsupported-inherit-css-function-method">The unsupported <code>inherit()</code> CSS function method</h3>


<p>The <code>inherit()</code> CSS function, which isn’t currently supported by any web browser, will enable us to get the value of a parent’s property. Think: the <code>inherit</code> keyword, except that we can get the value of <em>any</em> parent property and even modify it using value functions such as <code>calc()</code>. The <a href="https://www.w3.org/TR/css-values-5/#inherit-notation" rel="noopener">latest draft of the CSS Values and Units Module Level 5 spec</a> defines how this’d work for custom properties, which wouldn’t really enable us to do anything that we can’t already do (as demonstrated in the previous example), but the hope is that it’d work for all CSS properties further down the line so that we wouldn’t need to use custom properties (which is just a tad longer):</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">header {
  height: 3rem;

  button {
    height: 100%;

    /* Get height of parent but use it here */
    border-radius: calc(inherit(height) * 0.3);
    padding-inline: calc(inherit(height) * 0.5);
  }
}</code></pre>



<p>There is one difference between this and the custom properties approach, though. This method depends on the fixed height of the parent, whereas with the custom properties method either the parent or the child can have the fixed height.</p>



<p>This means that <code>inherit()</code> wouldn’t interpolate values. For example, an <code>auto</code> value that computes to <code>3rem</code> would still be inherited as <code>auto</code>, which might compute to something else when <code>inherit()</code>-ed., Sometimes that’d be fine, but other times it’d be an issue. Personally, I’m hoping that interpolation becomes a possibility at some point, making it far more useful than the custom properties method.</p>



<p>Until then, there are some other (mostly property-specific) options.</p>


<h3 class="wp-block-heading" id="the-aspect-ratio-css-property">The <code>aspect-ratio</code> CSS property</h3>


<p>Using the <a href="https://css-tricks.com/almanac/properties/a/aspect-ratio/"><code>aspect-ratio</code></a> CSS property, we can set the height relative to the width, and vice-versa. For example:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">div {
  width: 30rem;

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

  /* Same thing */
  aspect-ratio: 3 / 1.5;

  /* Same thing */
  aspect-ratio: 10 / 5;

  /* width and height will be the same */
  aspect-ratio: 1 / 1;
}</code></pre>



<p>Technically we don’t “get” the <code>width</code> or the <code>height</code>, but we do get to set one based on the other, which is the important thing (and since it’s a ratio, you don’t need to know the actual value — or unit — of either).</p>


<h3 class="wp-block-heading" id="the-currentcolor-css-keyword">The <code>currentColor</code> CSS keyword</h3>


<p>The <code>currentColor</code> CSS keyword resolves to the computed value of the <a href="https://css-tricks.com/almanac/properties/c/color/"><code>color</code></a> property. Its data type is <code>&lt;color&gt;</code>, so we can use it in place of any <code>&lt;color&gt;</code> on any property on the same element. For example, if we set the <code>color</code> to <code>red</code> (or something that resolves to <code>red</code>), or if the <code>color</code> is computed as <code>red</code> via inheritance, we could then declare <code>border-color: currentColor</code> to make the border red too:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">body {
  /* We can set color here (and let it be inherited) */
  color: red;

  button {
    /* Or set it here */
    color: red;

    /* And then use currentColor here */
    border-color: currentColor;
    border: 0.0625rem solid currentColor;
    background: hsl(from currentColor h s 90);
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_GgoOeXQ" src="//codepen.io/anon/embed/GgoOeXQ?height=450&amp;theme-id=1&amp;slug-hash=GgoOeXQ&amp;default-tab=css,result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed GgoOeXQ" title="CodePen Embed GgoOeXQ" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>This enables us to reuse the color without having to set up custom properties, and of course if the value of <code>color</code> changes, <code>currentColor</code> will automatically update to match it.</p>



<p>While this isn’t the same thing as being able to get the color of literally anything, it’s still pretty useful. Actually, if something akin to <code>compute(background-color)</code> just isn’t possible, I’d be happy with more CSS keywords like <code>currentColor</code>.</p>



<p>In fact, <code>currentBackgroundColor</code>/<code>currentBackground</code> has <a href="https://github.com/w3c/csswg-drafts/issues/5292" rel="noopener">already been proposed</a>. Using <code>currentBackgroundColor</code> for example, we could set the border color to be slightly darker than the background color (<code>border-color: hsl(from currentBackgroundColor h s calc(l - 30))</code>), or mix the background color with another color and then use that as the border color (<code>border-color: color-mix(currentBackgroundColor, black, 30)</code>).</p>



<p>But why stop there? Why not <code>currentWidth</code>, <code>currentHeight</code>, and so on?</p>


<h4 class="wp-block-heading" id="the-from-font-css-keyword">The <code>from-font</code> CSS keyword</h4>


<p>The <a href="https://css-tricks.com/from-font-value-text-decoration-thickness/"><code>from-font</code></a> CSS keyword is exclusive to the <a href="https://css-tricks.com/almanac/properties/t/text-decoration/text-decoration-thickness/"><code>text-decoration-thickness</code></a> property, which can be used to set the thickness of underlines. If you’ve ever hated the fact that underlines are always <code>1px</code> regardless of the <code>font-size</code> and <code>font-weight</code>, then <code>text-decoration-thickness</code> can fix that.</p>



<p>The <code>from-font</code> keyword doesn’t generate a value though — it’s optionally provided by the font maker and embedded into the font file, so you might not like the value that they provide, if they provide one at all. If they don’t, <code>auto</code> will be used as a fallback, which web browsers resolve to <code>1px</code>. This is fine if you aren’t picky, but it’s nonetheless unreliable (and obviously quite niche).</p>



<p>We can, however, specify a percentage value instead, which will ensure that the thickness is relative to the <code>font-size</code>. So, if <code>text-decoration-thickness: from-font</code> just isn’t cutting it, then we have that as a backup (something between <code>8%</code> and <code>12%</code> should do it).</p>


<h3 class="wp-block-heading" id="don-t-underestimate-css-units">Don’t underestimate CSS units</h3>


<p>You probably already know about <code>vw</code> and <code>vh</code> units (viewport width and viewport height units). These represent a percentage of the viewport’s width and height respectively, so <code>1vw</code> for example would be 1% of the viewport’s width. These units can be useful by themselves or within a <code>calc()</code> function, and used within any property that accepts a <code>&lt;length&gt;</code> unit.</p>



<p>However, <a href="https://css-tricks.com/css-length-units/">there are plenty of other, lesser-known units</a> that can be useful in a similar way:</p>



<ul class="wp-block-list">
<li><code>1ex</code>: equal to the computed x-height</li>



<li><code>1cap</code>: equal to the computed cap height</li>



<li><code>1ch</code>: equal to the computed width of the <code>0</code> glyph</li>



<li><code>1lh</code>: equal to the computed <code>line-height</code> (as long as you’re not trimming or adding to its content box, for example using <code>text-box</code> or <code>padding</code>, respectively, <code>lh</code> units could be used to determine the height of a box that has a fixed number of lines)</li>
</ul>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="361" height="97" src="https://css-tricks.com/wp-content/uploads/2025/10/Typography_Line_Terms.svg" alt="" class="wp-image-389945"/><figcaption class="wp-element-caption">Source: <a href="https://www.w3.org/TR/css-values-4/images/Typography_Line_Terms.svg" rel="noopener">W3</a></figcaption></figure>



<p>And again, you can use them, their logical variants (e.g., <code>vi</code> and <code>vb</code>), and their root variants (e.g., <code>rex</code> and <code>rcap</code>) within any property that accepts a <code>&lt;length&gt;</code> unit.</p>



<p>In addition, if you’re using <a href="https://css-tricks.com/css-container-queries/">container size queries</a>, you’re also free to use the following container query units within the containment contexts:</p>



<ul class="wp-block-list">
<li><code>1cqw</code>: equal to 1% of the container’s computed width</li>



<li><code>1cqh</code>: equal to 1% of the container’s computed height</li>



<li><code>1cqi</code>: equal to 1% of the container’s computed inline size</li>



<li><code>1cqb</code>: equal to 1% of the container’s computed block size</li>



<li><code>1cqmin</code>: equal to <code>1cqi</code> or <code>1cqb</code>, whichever is smallest</li>



<li><code>1cqmax</code>: equal to <code>1cqi</code> or <code>1cqb</code>, whichever is largest</li>
</ul>



<p>That <code>inherit()</code> example from earlier, you know, the one that isn’t currently supported by any web browser? Here’s the same thing but with container size queries:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">header {
  height: 3rem;
  container: header / size;

  @container header (width) {
    button {
      height: 100%;
      border-radius: calc(100cqh * 0.3);
      padding-inline: calc(100cqh * 0.5);
    }
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_GgoyQKa" src="//codepen.io/anon/embed/GgoyQKa?height=450&amp;theme-id=1&amp;slug-hash=GgoyQKa&amp;default-tab=css,result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed GgoyQKa" title="CodePen Embed GgoyQKa" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>Or, since we’re talking about a container and its direct child, we can use the following shorter version that doesn’t create and query a named container (we don’t need to query the container anyway, since all we’re doing is stealing its units!):</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">header {
  height: 3rem;
  container-type: size;

  button {
    height: 100%;
    border-radius: calc(100cqh * 0.3);
    padding-inline: calc(100cqh * 0.5);
  }
}</code></pre>



<p>However, keep in mind that <code>inherit()</code> would enable us to inherit <em>anything</em>, whereas container size queries only enable us to inherit sizes. Also, container size queries don’t work with inline containers (that’s why this version of the container is horizontally stretched), so they can’t solve every problem anyway.</p>


<h3 class="wp-block-heading" id="in-a-nutshell">In a nutshell</h3>


<p>I’m just going to throw <code>compute()</code> out there again, because I think it’d be a really great way to get the values of other CSS properties:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">button {
  /* self could be the default */
  border-radius: compute(height, self);
  /* inherit could work like inherit() */
  border-radius: compute(height, inherit);
  /* Nice to have, but not as important */
  border-radius: compute(height, #this);
}</code></pre>



<p>But if it’s just not possible, I really like the idea of introducing more <code>currentColor</code>-like keywords. With the exception of keywords like <code>from-font</code> where the font maker provides the value (or not, <em>sigh</em>), keywords such as <code>currentWidth</code> and <code>currentHeight</code> would be incredibly useful. They’d make CSS easier to read, and we wouldn’t have to create as many custom properties.</p>



<p>In the meantime though, custom properties, <code>aspect-ratio</code>, and certain CSS units can help us in the right circumstances, not to mention that we’ll be getting <code>inherit()</code> in the future. These are heavily geared towards getting widths and heights, which is fine because that’s undoubtedly the biggest problem here, but hopefully there are more CSS features on the horizon that allow values to be used in more places.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/on-inheriting-and-sharing-property-values/">On Inheriting and Sharing Property Values</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Sometimes I want to set the value of a CSS property to that of a different property, even if I don’t know what that value is, and even if it changes later. Unfortunately though, that’s not possible (at least, there isn’t a CSS function that specifically does that).




In my opinion, it’d be super useful to have something like this (for interpolation, maybe you’d throw calc-size() in there as well):
/* Totally hypothetical */
button {
  border-radius: compute(height, self);
  border-radius: compute(height, inherit);
  border-radius: compute(height, #this);
}
In 2021, Lea Verou explained why, despite being proposed numerous times, implementing such a general-purpose CSS function like this isn’t feasible. Having said that, I do remain hopeful, because things are always evolving and the CSSWG process isn’t always linear.
In the meantime, even though there isn’t a CSS function that enables us to get the value of a different property, you might be able to achieve your outcome using a different method, and those methods are what we’re going to look at today.
The fool-proof CSS custom properties method
We can easily get the value of a different CSS property using custom properties, but we’d need to know what the value is in order to declare the custom property to begin with. This isn’t ideal, but it does enable us to achieve some outcomes.
Let’s jump back to the example from the intro where we try to set the border-radius based on the height, only this time we know what the height is and we store it as a CSS custom property for reusability, and so we’re able to achieve our outcome:
button {
  --button-height: 3rem;
  height: var(--button-height);
  border-radius: calc(var(--button-height) * 0.3);
}
We can even place that --button-height custom property higher up in the CSS cascade to make it available to more containment contexts.
:root {
  /* Declare here to use anywhere */
  --button-height: 3rem;

  header {
    --header-padding: 1rem;
    padding: var(--header-padding);
  
    /* Height is unknown (but we can calculate it) */
    --header-height: calc(var(--button-height) + (var(--header-padding) * 2));
  
    /* Which means we can calculate this, too */
    border-radius: calc(var(--header-height) * 0.3);
  
    button {
      /* As well as these, of course */
      height: var(--button-height);
      border-radius: calc(var(--button-height) * 0.3);

      /* Oh, what the heck */
      padding-inline: calc(var(--button-height) * 0.5);
    }
  }
}
CodePen Embed Fallback
I guess when my math teacher said that I’d need algebra one day. She wasn’t lying!
The unsupported inherit() CSS function method
The inherit() CSS function, which isn’t currently supported by any web browser, will enable us to get the value of a parent’s property. Think: the inherit keyword, except that we can get the value of any parent property and even modify it using value functions such as calc(). The latest draft of the CSS Values and Units Module Level 5 spec defines how this’d work for custom properties, which wouldn’t really enable us to do anything that we can’t already do (as demonstrated in the previous example), but the hope is that it’d work for all CSS properties further down the line so that we wouldn’t need to use custom properties (which is just a tad longer):
header {
  height: 3rem;

  button {
    height: 100%;

    /* Get height of parent but use it here */
    border-radius: calc(inherit(height) * 0.3);
    padding-inline: calc(inherit(height) * 0.5);
  }
}
There is one difference between this and the custom properties approach, though. This method depends on the fixed height of the parent, whereas with the custom properties method either the parent or the child can have the fixed height.
This means that inherit() wouldn’t interpolate values. For example, an auto value that computes to 3rem would still be inherited as auto, which might compute to something else when inherit()-ed., Sometimes that’d be fine, but other times it’d be an issue. Personally, I’m hoping that interpolation becomes a possibility at some point, making it far more useful than the custom properties method.
Until then, there are some other (mostly property-specific) options.
The aspect-ratio CSS property
Using the aspect-ratio CSS property, we can set the height relative to the width, and vice-versa. For example:
div {
  width: 30rem;

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

  /* Same thing */
  aspect-ratio: 3 / 1.5;

  /* Same thing */
  aspect-ratio: 10 / 5;

  /* width and height will be the same */
  aspect-ratio: 1 / 1;
}
Technically we don’t “get” the width or the height, but we do get to set one based on the other, which is the important thing (and since it’s a ratio, you don’t need to know the actual value — or unit — of either).
The currentColor CSS keyword
The currentColor CSS keyword resolves to the computed value of the color property. Its data type is <color>, so we can use it in place of any <color> on any property on the same element. For example, if we set the color to red (or something that resolves to red), or if the color is computed as red via inheritance, we could then declare border-color: currentColor to make the border red too:
body {
  /* We can set color here (and let it be inherited) */
  color: red;

  button {
    /* Or set it here */
    color: red;

    /* And then use currentColor here */
    border-color: currentColor;
    border: 0.0625rem solid currentColor;
    background: hsl(from currentColor h s 90);
  }
}
CodePen Embed Fallback
This enables us to reuse the color without having to set up custom properties, and of course if the value of color changes, currentColor will automatically update to match it.
While this isn’t the same thing as being able to get the color of literally anything, it’s still pretty useful. Actually, if something akin to compute(background-color) just isn’t possible, I’d be happy with more CSS keywords like currentColor.
In fact, currentBackgroundColor/currentBackground has already been proposed. Using currentBackgroundColor for example, we could set the border color to be slightly darker than the background color (border-color: hsl(from currentBackgroundColor h s calc(l - 30))), or mix the background color with another color and then use that as the border color (border-color: color-mix(currentBackgroundColor, black, 30)).
But why stop there? Why not currentWidth, currentHeight, and so on?
The from-font CSS keyword
The from-font CSS keyword is exclusive to the text-decoration-thickness property, which can be used to set the thickness of underlines. If you’ve ever hated the fact that underlines are always 1px regardless of the font-size and font-weight, then text-decoration-thickness can fix that.
The from-font keyword doesn’t generate a value though — it’s optionally provided by the font maker and embedded into the font file, so you might not like the value that they provide, if they provide one at all. If they don’t, auto will be used as a fallback, which web browsers resolve to 1px. This is fine if you aren’t picky, but it’s nonetheless unreliable (and obviously quite niche).
We can, however, specify a percentage value instead, which will ensure that the thickness is relative to the font-size. So, if text-decoration-thickness: from-font just isn’t cutting it, then we have that as a backup (something between 8% and 12% should do it).
Don’t underestimate CSS units
You probably already know about vw and vh units (viewport width and viewport height units). These represent a percentage of the viewport’s width and height respectively, so 1vw for example would be 1% of the viewport’s width. These units can be useful by themselves or within a calc() function, and used within any property that accepts a <length> unit.
However, there are plenty of other, lesser-known units that can be useful in a similar way:
1ex: equal to the computed x-height
1cap: equal to the computed cap height
1ch: equal to the computed width of the 0 glyph
1lh: equal to the computed line-height (as long as you’re not trimming or adding to its content box, for example using text-box or padding, respectively, lh units could be used to determine the height of a box that has a fixed number of lines)
Source: W3



And again, you can use them, their logical variants (e.g., vi and vb), and their root variants (e.g., rex and rcap) within any property that accepts a <length> unit.
In addition, if you’re using container size queries, you’re also free to use the following container query units within the containment contexts:
1cqw: equal to 1% of the container’s computed width
1cqh: equal to 1% of the container’s computed height
1cqi: equal to 1% of the container’s computed inline size
1cqb: equal to 1% of the container’s computed block size
1cqmin: equal to 1cqi or 1cqb, whichever is smallest
1cqmax: equal to 1cqi or 1cqb, whichever is largest
That inherit() example from earlier, you know, the one that isn’t currently supported by any web browser? Here’s the same thing but with container size queries:
header {
  height: 3rem;
  container: header / size;

  @container header (width) {
    button {
      height: 100%;
      border-radius: calc(100cqh * 0.3);
      padding-inline: calc(100cqh * 0.5);
    }
  }
}
CodePen Embed Fallback
Or, since we’re talking about a container and its direct child, we can use the following shorter version that doesn’t create and query a named container (we don’t need to query the container anyway, since all we’re doing is stealing its units!):
header {
  height: 3rem;
  container-type: size;

  button {
    height: 100%;
    border-radius: calc(100cqh * 0.3);
    padding-inline: calc(100cqh * 0.5);
  }
}
However, keep in mind that inherit() would enable us to inherit anything, whereas container size queries only enable us to inherit sizes. Also, container size queries don’t work with inline containers (that’s why this version of the container is horizontally stretched), so they can’t solve every problem anyway.
In a nutshell
I’m just going to throw compute() out there again, because I think it’d be a really great way to get the values of other CSS properties:
button {
  /* self could be the default */
  border-radius: compute(height, self);
  /* inherit could work like inherit() */
  border-radius: compute(height, inherit);
  /* Nice to have, but not as important */
  border-radius: compute(height, #this);
}
But if it’s just not possible, I really like the idea of introducing more currentColor-like keywords. With the exception of keywords like from-font where the font maker provides the value (or not, sigh), keywords such as currentWidth and currentHeight would be incredibly useful. They’d make CSS easier to read, and we wouldn’t have to create as many custom properties.
In the meantime though, custom properties, aspect-ratio, and certain CSS units can help us in the right circumstances, not to mention that we’ll be getting inherit() in the future. These are heavily geared towards getting widths and heights, which is fine because that’s undoubtedly the biggest problem here, but hopefully there are more CSS features on the horizon that allow values to be used in more places.
On Inheriting and Sharing Property Values originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

There are many ways to share properties, but what would it look like to inherit and use any parent property value on a child?
On Inheriting and Sharing Property Values originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

On Inheriting and Sharing Property Values

<p>Sketch probably didn't "have" to redesign its UI to line up with macOS Tahoe, but a big part of its appeal is the fact that it feels like it totally belongs to the Mac.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/sketch-a-guided-tour-of-copenhagen/">Sketch: A guided tour of Copenhagen</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>Sketch is getting a massive UI overhaul, <a href="https://www.sketch.com/blog/a-tour-of-copenhagen/" rel="noopener">codenamed Copenhagen</a>:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Our latest update — <a href="https://www.sketch.com/changelog/copenhagen/" rel="noopener">Copenhagen</a> — features a major redesign of Sketch’s UI. Redesigns like this don’t happen often. In fact, our last one was in 2020, when Apple launched macOS Big Sur.</p>
</blockquote>



<span id="more-390539"></span>



<p>Makes a lot of sense for an app that&#8217;s so tightly integrated to Mac to design around the macOS UI. Big Sur was a big update. Apple <a href="https://www.apple.com/newsroom/2020/06/apple-introduces-macos-big-sur-with-a-beautiful-new-design/" rel="noopener">called it</a> the biggest one since Mac OS X. So big, indeed, that they renamed Mac OS to macOS in the process. Now we have macOS Tahoe and while it isn&#8217;t billed the &#8220;biggest update since Big Sur&#8221; it does lean into an entirely new <a href="https://css-tricks.com/getting-clarity-on-apples-liquid-glass/">Liquid Glass</a> aesthetic that many are calling <a href="https://9to5mac.com/2025/05/30/remembering-the-controversial-ios-7-introduction/" rel="noopener">the biggest design update to the Apple ecosystem since iOS 7</a>.</p>



<p>Sketch probably didn&#8217;t &#8220;have&#8221; to redesign its UI to line up with macOS Tahoe, but a big part of its appeal is the fact that it feels like it totally belongs to the Mac. It&#8217;s the same for <a href="https://www.panic.com" rel="noopener">Panic apps</a>.</p>



<p>The blog post I linked to sheds a good amount of light on the Sketch team&#8217;s approach to the updates. I came to the blog post to read about the attention they put into new features (individual page and frame link for the win!) and tightening up existing ones (that layer list looks <em>nice</em>), but what I really stayed for was their approach to Liquid Glass. Turns out they decided to respect it, but split lanes a bit:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Early on in the process, we prototyped various approaches to the sidebar and Inspector, including floating options (the new default in Tahoe) and glass materials. Ultimately, we went custom here, with fixed sidebars that felt less distracting in the context of a canvas-based design tool.</p>
</blockquote>



<p>Spend a few seconds with an early prototype that leaned more heavily into Liquid Glass and it&#8217;s uber clear why a custom route was the best lane choice:</p>



<figure class="wp-block-image size-full"><img data-recalc-dims="1" loading="lazy" decoding="async" width="2560" height="1421" src="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/Screenshot-2025-11-20-at-11.06.28-AM-scaled.png?resize=2560%2C1421&#038;ssl=1" alt="Showing two translucent columns on the right and left of an app window containing a full-width grid of color tiles. The tiles show through the columns, distorting the UI." class="wp-image-390541" srcset="https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/Screenshot-2025-11-20-at-11.06.28-AM-scaled.png?w=2560&amp;ssl=1 2560w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/Screenshot-2025-11-20-at-11.06.28-AM-scaled.png?resize=300%2C166&amp;ssl=1 300w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/Screenshot-2025-11-20-at-11.06.28-AM-scaled.png?resize=1024%2C568&amp;ssl=1 1024w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/Screenshot-2025-11-20-at-11.06.28-AM-scaled.png?resize=768%2C426&amp;ssl=1 768w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/Screenshot-2025-11-20-at-11.06.28-AM-scaled.png?resize=1536%2C852&amp;ssl=1 1536w, https://i0.wp.com/css-tricks.com/wp-content/uploads/2025/11/Screenshot-2025-11-20-at-11.06.28-AM-scaled.png?resize=2048%2C1136&amp;ssl=1 2048w" sizes="auto, (min-width: 735px) 864px, 96vw" /><figcaption class="wp-element-caption">Still taken from one of the blog post&#8217;s embedded videos</figcaption></figure>



<p>Choosing a design editor can feel personal, can&#8217;t it? I know lots of folks are in the <a href="https://www.figma.com" rel="noopener">Figma</a> Or Bust camp. <a href="https://www.adobe.com/products/illustrator.html#modal-hash" rel="noopener">Illustrator</a> is still the favorite child for many, after all these&#8230; decades! There&#8217;s a lot of buzz around <a href="https://www.affinity.studio/get-affinity" rel="noopener">Affinity</a> now that it&#8217;s totally free. I adopted <a href="https://www.sketch.com" rel="noopener">Sketch</a> a long time ago. How long? I dug up <a href="https://geoffgraham.me/first-impressions-of-sketch-3/" rel="noopener">this dusty old blog post</a> I wrote about Sketch 3 back in 2014, so at least 11 years.</p>



<p>But I&#8217;m more of a transient in the design editor space. Being a contractor and all, I have to be open to any app my clients might use internally, regardless of my personal preference. I&#8217;d brush up on Sketch&#8217;s UI updates even if it wasn&#8217;t my go-to.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/sketch-a-guided-tour-of-copenhagen/">Sketch: A guided tour of Copenhagen</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


Sketch is getting a massive UI overhaul, codenamed Copenhagen:
Our latest update — Copenhagen — features a major redesign of Sketch’s UI. Redesigns like this don’t happen often. In fact, our last one was in 2020, when Apple launched macOS Big Sur.




Makes a lot of sense for an app that’s so tightly integrated to Mac to design around the macOS UI. Big Sur was a big update. Apple called it the biggest one since Mac OS X. So big, indeed, that they renamed Mac OS to macOS in the process. Now we have macOS Tahoe and while it isn’t billed the “biggest update since Big Sur” it does lean into an entirely new Liquid Glass aesthetic that many are calling the biggest design update to the Apple ecosystem since iOS 7.
Sketch probably didn’t “have” to redesign its UI to line up with macOS Tahoe, but a big part of its appeal is the fact that it feels like it totally belongs to the Mac. It’s the same for Panic apps.
The blog post I linked to sheds a good amount of light on the Sketch team’s approach to the updates. I came to the blog post to read about the attention they put into new features (individual page and frame link for the win!) and tightening up existing ones (that layer list looks nice), but what I really stayed for was their approach to Liquid Glass. Turns out they decided to respect it, but split lanes a bit:
Early on in the process, we prototyped various approaches to the sidebar and Inspector, including floating options (the new default in Tahoe) and glass materials. Ultimately, we went custom here, with fixed sidebars that felt less distracting in the context of a canvas-based design tool.
Spend a few seconds with an early prototype that leaned more heavily into Liquid Glass and it’s uber clear why a custom route was the best lane choice:
Still taken from one of the blog post’s embedded videos



Choosing a design editor can feel personal, can’t it? I know lots of folks are in the Figma Or Bust camp. Illustrator is still the favorite child for many, after all these… decades! There’s a lot of buzz around Affinity now that it’s totally free. I adopted Sketch a long time ago. How long? I dug up this dusty old blog post I wrote about Sketch 3 back in 2014, so at least 11 years.
But I’m more of a transient in the design editor space. Being a contractor and all, I have to be open to any app my clients might use internally, regardless of my personal preference. I’d brush up on Sketch’s UI updates even if it wasn’t my go-to.
Sketch: A guided tour of Copenhagen originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Sketch probably didn't "have" to redesign its UI to line up with macOS Tahoe, but a big part of its appeal is the fact that it feels like it totally belongs to the Mac.
Sketch: A guided tour of Copenhagen originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Sketch: A guided tour of Copenhagen

<p>Is there really a difference between using <code>:not(:open)</code> and <code>:closed</code>? As always, it depends. Sunkanmi Fafowora explains why <code>:closed</code> is currently not a thing.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/should-we-even-have-closed/">Should We Even Have :closed?</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>For the past few months, I&#8217;ve been writing a lot of entries on pseudo-selectors in CSS, like&nbsp;<a href="https://css-tricks.com/almanac/pseudo-selectors/p/picker/"><code>::picker()</code></a>&nbsp;or&nbsp;<a href="https://css-tricks.com/almanac/pseudo-selectors/c/checkmark/"><code>::checkmark</code></a>. And, in the process, I noticed I tend to use the&nbsp;<code>:open</code>&nbsp;pseudo-selector a lot in my examples — and in my work in general.</p>



<p>Borrowing words from the fine author of the&nbsp;<code><a href="https://css-tricks.com/almanac/pseudo-selectors/o/open/">:open</a></code> entry in the Almanac:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>The CSS&nbsp;<code>:open</code>&nbsp;pseudo-selector targets elements that support open and closed states — such as the&nbsp;<code>&lt;details&gt;</code>&nbsp;and&nbsp;<code>&lt;select&gt;</code>&nbsp;elements — and selects them in their&nbsp;<strong>open state</strong>.</p>
</blockquote>



<span id="more-390115"></span>



<p>So, given this:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">details:open {
  background: lightblue;
  color: darkred;
}</code></pre>



<p>We expect that the <code>&lt;details&gt;</code> element gets a light blue background and dark red text when it is in an open state (everywhere but Safari at the time I&#8217;m writing this):</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_gbPRoPp" src="//codepen.io/anon/embed/gbPRoPp?height=450&amp;theme-id=1&amp;slug-hash=gbPRoPp&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed gbPRoPp" title="CodePen Embed gbPRoPp" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>But what if we want to select the &#8220;closed&#8221;&nbsp;state instead? That&#8217;s what we have the<code>:closed</code>&nbsp;pseudo-class for, right? It&#8217;s&nbsp;<a href="https://github.com/w3c/csswg-drafts/issues/11039#issuecomment-2414919685" rel="noopener">supposed&nbsp;to match an element&#8217;s closed state</a>. I say,&nbsp;<em>supposed</em>&nbsp;because it&#8217;s not specced yet.</p>



<p>But does it need to be specced at all? I only ask because we can still target an element&#8217;s closed state without it using <code><a href="https://css-tricks.com/almanac/pseudo-selectors/n/not/">:not()</a></code>:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* When details is _not_ open, but closed */
details:not(:open) {
  /* ... */
}</code></pre>



<p>So, again: do we really need a&nbsp;<code>:closed</code>&nbsp;pseudo-class?  The answer may surprise you! (Just kidding, this isn&#8217;t that sort of article&#8230;)</p>


<h3 class="wp-block-heading" id="the-genesis">Some background</h3>


<p>Talks surrounding&nbsp;<code>:open</code>&nbsp;started in May 2022 when&nbsp;<a href="https://github.com/mfreed7" rel="noopener">Mason Freed</a>&nbsp;raised&nbsp;<a href="https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-2414693787" rel="noopener">the issue</a>&nbsp;of adding&nbsp;<code>:open</code>&nbsp;(which was also considered being named&nbsp;<code>:top-layer</code> at the time) to target elements in the top layer (like popups):</p>



<p>Today, the OpenUI WC similarly&nbsp;<a href="https://github.com/openui/open-ui/issues/470#issuecomment-1138868669" rel="noopener">resolved</a>&nbsp;to add a&nbsp;<code>:top-layer</code>&nbsp;pseudo class that should apply to (at least) elements using the&nbsp;<a href="https://open-ui.org/components/popup.research.explainer" rel="noopener">Popup API</a>&nbsp;which are currently in the top layer. The intention for the naming and behavior, though, was that this pseudo class should also be general purpose. It should match any type of element in the top layer, including modal&nbsp;<code>&lt;dialog&gt;</code>, fullscreen elements, and&nbsp;<code>::backdrop</code>&nbsp;pseudo elements.</p>



<p>This sparked discourse on whether the name of the pseudo-element targeting the top layer of any type of element (e.g., popups, pickers, etc.) should either be&nbsp;<code>:open</code>&nbsp;or&nbsp;<code>:top-layer</code>. I, for one, was thrilled when the&nbsp;<a href="https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1225988203" rel="noopener">CSSWG eventually decided on <code>:open</code></a>&nbsp;in August 2022. The name makes a lot more sense to me because &#8220;open&#8221; assumes something in the top layer.</p>


<h3 class="wp-block-heading" id="to-close-or-notopen">To <code>:close</code> or <code>:not(:open)</code>?</h3>


<p>Hold on, though! In September that same year,&nbsp;Mason asked whether or not we should have something like a&nbsp;<code>:closed</code>&nbsp;pseudo-class to accompany <code>:open</code>. That way, we can match elements in their “closed” states just as we can their &#8220;open&#8221; states. That makes a lot of sense, t least on the surface. <a href="https://github.com/tabatkins" rel="noopener">Tab Atkins</a>&nbsp;chimed in:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>I love this definition, as I think it captures a concept of &#8220;openness&#8221; that lines up with what most developers think &#8220;open&#8221; means. I also think it makes it relatively straightforward for HTML to connect it to specific elements.</p>



<p>What do folks think?</p>



<p>Should we also talk about adding the corresponding&nbsp;<code>:closed</code>&nbsp;pseudo class? That would avoid the problem that&nbsp;<code>:not(:open)</code>&nbsp;<em>can match anything</em>, including things that don&#8217;t open or close.</p>
</blockquote>



<p>And guess what? Everyone seemed to agree. Why? Because it made sense at the time. I mean, since we have a pseudo-class that targets elements in their&nbsp;<code>:open</code>&nbsp;state, surely it makes sense to have&nbsp;<code>:closed</code>&nbsp;to target elements in their closed states, right? Right??</p>



<p><strong>No</strong>. There’s actually an issue with that line of reasoning. <a href="https://github.com/josepharhar" rel="noopener">Joey Arhar</a>&nbsp;made a&nbsp;<a href="https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-2414693787" rel="noopener">comment about it</a>&nbsp;in October that same year:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>I opened a new issue about&nbsp;<code>:closed</code>&nbsp;because this doesn&#8217;t have consensus yet (<a href="https://github.com/w3c/csswg-drafts/issues/11039" rel="noopener">#11039</a>).</p>
</blockquote>



<p>Wait, what happened to consensus? It&#8217;s the same question I raised at the top of this post. According to&nbsp;<a href="https://github.com/lukewarlow" rel="noopener">Luke Warlow</a>:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Making&nbsp;<code>:closed</code>&nbsp;match things that can never be open feels odd. And would essentially make it&nbsp;<code>:not(:open)</code>&nbsp;in which case do we even need&nbsp;<code>:closed</code>? Like we don&#8217;t have a&nbsp;<code>:popover-closed</code>&nbsp;because it&#8217;s the inverse of&nbsp;<code>:popover-open</code>.</p>
</blockquote>


<h3 class="wp-block-heading" id="there-is-no-closed-for-now">There is no <code>:closed</code>&#8230; for now</h3>


<p>Fast forward one more month to November 2024. A consensus was made to start out with just&nbsp;<code>:open</code>&nbsp;and&nbsp;<a href="https://github.com/whatwg/html/pull/10126#issuecomment-2501899670" rel="noopener">remove&nbsp;<code>:closed</code>&nbsp;for the time being</a>.</p>



<p>Dang. Nevertheless, according to&nbsp;<a href="https://github.com/whatwg/html/pull/10126#issuecomment-2501899670" rel="noopener">WHATWG</a>&nbsp;and&nbsp;<a href="https://github.com/w3c/csswg-drafts/issues/11039#issuecomment-2491673891" rel="noopener">CSSWG</a>, that decision could change in the future. In fact, <a href="https://www.bram.us" rel="noopener">Bramus</a> dropped a useful note in there just a month before WHATWG made the decision:</p>



<p>Just dropping this as an FYI:&nbsp;<code>:read-only</code>&nbsp;is defined as&nbsp;<code>:not(:read-write)</code>, and&nbsp;<a href="https://html.spec.whatwg.org/multipage/semantics-other.html#selector-read-only" rel="noopener">that shipped</a>.</p>


<h3 class="wp-block-heading" id="which-do-you-find-easier-to-understand">Which do you find easier to understand?</h3>


<p>Personally, I’m okay with&nbsp;<code>:closed</code>&nbsp;— or even using&nbsp;<code>:not(:open)</code> — so far as it works. In fact, I went ahead swapped <code>:closed</code> for <code>:not(:open)</code> in my &nbsp;<code><a href="https://css-tricks.com/almanac/pseudo-selectors/c/checkmark/">::checkmark</a></code> and&nbsp;<a href="https://css-tricks.com/almanac/pseudo-selectors/p/picker/"><code>::picker()</code></a> examples. That&#8217;s why they are they way they are today.</p>



<p>But! If you were to ask me which one comes easier to me on a typical day, I think I would say <code>:closed</code>. It&#8217;s easier for me to think in literal terms than negated statements.</p>



<p>What do you think, though? Would you prefer having&nbsp;<code>:closed</code>&nbsp;or just leaving it as&nbsp;<code>:not(:open)</code>?</p>



<p class="is-style-explanation">If you’re like me and you love following discussions like this, you can always head over to&nbsp;<a href="https://github.com/w3c/csswg-drafts" rel="noopener">CSSWG drafts on GitHub</a> to watch or participate in the fun.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/should-we-even-have-closed/">Should We Even Have :closed?</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


For the past few months, I’ve been writing a lot of entries on pseudo-selectors in CSS, like ::picker() or ::checkmark. And, in the process, I noticed I tend to use the :open pseudo-selector a lot in my examples — and in my work in general.
Borrowing words from the fine author of the :open entry in the Almanac:
The CSS :open pseudo-selector targets elements that support open and closed states — such as the <details> and <select> elements — and selects them in their open state.




So, given this:
details:open {
  background: lightblue;
  color: darkred;
}
We expect that the <details> element gets a light blue background and dark red text when it is in an open state (everywhere but Safari at the time I’m writing this):
CodePen Embed Fallback
But what if we want to select the “closed” state instead? That’s what we have the:closed pseudo-class for, right? It’s supposed to match an element’s closed state. I say, supposed because it’s not specced yet.
But does it need to be specced at all? I only ask because we can still target an element’s closed state without it using :not():
/* When details is _not_ open, but closed */
details:not(:open) {
  /* ... */
}
So, again: do we really need a :closed pseudo-class?  The answer may surprise you! (Just kidding, this isn’t that sort of article…)
Some background
Talks surrounding :open started in May 2022 when Mason Freed raised the issue of adding :open (which was also considered being named :top-layer at the time) to target elements in the top layer (like popups):
Today, the OpenUI WC similarly resolved to add a :top-layer pseudo class that should apply to (at least) elements using the Popup API which are currently in the top layer. The intention for the naming and behavior, though, was that this pseudo class should also be general purpose. It should match any type of element in the top layer, including modal <dialog>, fullscreen elements, and ::backdrop pseudo elements.
This sparked discourse on whether the name of the pseudo-element targeting the top layer of any type of element (e.g., popups, pickers, etc.) should either be :open or :top-layer. I, for one, was thrilled when the CSSWG eventually decided on :open in August 2022. The name makes a lot more sense to me because “open” assumes something in the top layer.
To :close or :not(:open)?
Hold on, though! In September that same year, Mason asked whether or not we should have something like a :closed pseudo-class to accompany :open. That way, we can match elements in their “closed” states just as we can their “open” states. That makes a lot of sense, t least on the surface. Tab Atkins chimed in:
I love this definition, as I think it captures a concept of “openness” that lines up with what most developers think “open” means. I also think it makes it relatively straightforward for HTML to connect it to specific elements.
What do folks think?
Should we also talk about adding the corresponding :closed pseudo class? That would avoid the problem that :not(:open) can match anything, including things that don’t open or close.
And guess what? Everyone seemed to agree. Why? Because it made sense at the time. I mean, since we have a pseudo-class that targets elements in their :open state, surely it makes sense to have :closed to target elements in their closed states, right? Right??
No. There’s actually an issue with that line of reasoning. Joey Arhar made a comment about it in October that same year:
I opened a new issue about :closed because this doesn’t have consensus yet (#11039).
Wait, what happened to consensus? It’s the same question I raised at the top of this post. According to Luke Warlow:
Making :closed match things that can never be open feels odd. And would essentially make it :not(:open) in which case do we even need :closed? Like we don’t have a :popover-closed because it’s the inverse of :popover-open.
There is no :closed… for now
Fast forward one more month to November 2024. A consensus was made to start out with just :open and remove :closed for the time being.
Dang. Nevertheless, according to WHATWG and CSSWG, that decision could change in the future. In fact, Bramus dropped a useful note in there just a month before WHATWG made the decision:
Just dropping this as an FYI: :read-only is defined as :not(:read-write), and that shipped.
Which do you find easier to understand?
Personally, I’m okay with :closed — or even using :not(:open) — so far as it works. In fact, I went ahead swapped :closed for :not(:open) in my  ::checkmark and ::picker() examples. That’s why they are they way they are today.
But! If you were to ask me which one comes easier to me on a typical day, I think I would say :closed. It’s easier for me to think in literal terms than negated statements.
What do you think, though? Would you prefer having :closed or just leaving it as :not(:open)?
If you’re like me and you love following discussions like this, you can always head over to CSSWG drafts on GitHub to watch or participate in the fun.
Should We Even Have :closed? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Is there really a difference between using :not(:open) and :closed? As always, it depends. Sunkanmi Fafowora explains why :closed is currently not a thing.
Should We Even Have :closed? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Should We Even Have :closed?

<p>If we have a ratio that represents the sine, cosine or tangent of an angle, how can we get the original angle? This is where inverse trigonometric functions come in!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/the-most-hated-css-feature-asin-acos-atan-and-atan2/">The “Most Hated” CSS Feature: asin(), acos(), atan() and atan2()</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


This is a series! It all started a couple of articles ago, when we found out that, according to the State of CSS 2025 survey, trigonometric functions were the “Most Hated” CSS feature.








I’ve been trying to change that perspective, so I showcased several uses for trigonometric functions in CSS: one for sin() and cos() and another on tan(). However, that’s only half of what trigonometric functions can do. So today, we’ll poke at the inverse world of trigonometric functions: asin(), acos(), atan() and atan2().

CSS Trigonometric Functions: The “Most Hated” CSS Feature
sin() and cos() 
tan()
asin(), acos(), atan() and atan2() (You are here!)



Inverse functions?
Recapping things a bit, given an angle, the sin(), cos() and tan() functions return a ratio presenting the sine, cosine, and tangent of that angle, respectively. And if you read the last two parts of the series, then you already know what each of those quantities represents.
What if we wanted to go the other way around? If we have a ratio that represents the sine, cosine or tangent of an angle, how can we get the original angle? This is where inverse trigonometric functions come in! Each inverse function asks what the necessary angle is to get a given value for a specific trigonometric function; in other words, it undoes the original trigonometric function. So…
acos() is the inverse of cos(),
asin() is the inverse of sin(), and
atan() and atan2() are the inverse of tan().
They are also called “arcus” functions and written as arcos(), arcsin() and arctan() in most places. This is because, in a circle, each angle corresponds to an arc in the circumference.
CodePen Embed Fallback
The length of this arc is the angle times the circle’s radius. Since trigonometric functions live in a unit circle, where the radius is equal to 1, the arc length is also the angle, expressed in radians.
Their mathy definitions are a little boring, to say the least, but they are straightforward:
y = acos(x) such that x = cos(y)
y = asin(x) such that x = sin(y)
y = atan(x) such that x = tan(y)
acos() and asin()
Using acos() and asin(), we can undo cos(θ) and sin(θ) to get the starting angle, θ. However, if we try to graph them, we’ll notice something odd:




The functions are only defined from -1 to 1!
Remember, cos() and sin() can take any angle, but they will always return a number between -1 and 1. For example, both cos(90°) and cos(270°) (not to mention others) return 0, so which value should acos(0) return? To answer this, both acos() and asin() have their domain (their input) and range (their output) restricted:
acos() can only take numbers between -1 and 1 and return angles between 0° and 180°.
asin() can only take numbers between -1 and 1 and return angles between -90° and 90°.
This limits a lot of the situations where we can use acos() and asin(), since something like asin(1.2) doesn’t work in CSS* — according to the spec, going outside acos() and asin() domain returns NaN — which leads us to our next inverse function…
atan() and atan2()
Similarly, using atan(), we can undo tan(θ) to get θ. But, unlike asin() and acos(), if we graph it, we’ll notice a big difference:




This time it is defined on the whole number line! This makes sense since tan() can return any number between -Infinity and Infinity, so atan() is defined in that domain.
atan() can take any number between -Infinity and Infinity and returns angles -90° and 90°.
This makes atan() incredibly useful to find angles in all kinds of situations, and a lot more versatile than acos() and asin(). That’s why we’ll be using it, along atan2(), going forward. Although don’t worry about atan2() for now, we’ll get to it later.
Finding the perfect angle
In the last article, we worked a lot with triangles. Specifically, we used the tan() function to find one of the sides of a right-angled triangle from the following relationships:




To make it work, we needed to know one of its sides and the angle, and by solving the equation, we would get the other side. However, in most cases, we do know the lengths of the triangle’s sides and what we are actually looking for is the angle. In that case, the last equation becomes:



Triangles and Conic Gradients
Finding the angle comes in handy in lots of cases, like in gradients, for instance. In a linear gradient, for example, if we want it to go from corner to corner, we’ll have to match the gradient’s angle depending on the element’s dimensions. Otherwise, with a fixed angle, the gradient won’t change if the element gets resized:
.gradient {
  background: repeating-linear-gradient(ghostwhite 0px 25px, darkslategray 25px 50px);
}
CodePen Embed Fallback
This may be the desired look, but I think that most often than not, you want it to match the element’s dimensions.
Using linear-gradient(), we can easily solve this using to top right or to bottom left values for the angle, which automatically sets the angle so the gradient goes from corner to corner.
.gradient {
  background: repeating-linear-gradient(to top right, ghostwhite 0px 25px, darkslategray 25px 50px);
}
CodePen Embed Fallback
However, we don’t have that type of syntax for other gradients, like a conic-gradient(). For example, the next conic gradient has a fixed angle and won’t change upon resizing the element.
.gradient {
  background: conic-gradient(from 45deg, #84a59d 180deg, #f28482 180deg);
}
CodePen Embed Fallback
Luckily, we can fix this using atan()! We can look at the gradient as a right-angled triangle, where the width is the adjacent side and the height the opposite side:




Then, we can get the angle using this formula:
.gradient {
  --angle: atan(var(--height-gradient) / var(--width-gradient));
}
Since conic-gradient() starts from the top edge — conic-gradient(from 0deg) — we’ll have to shift it by 90deg to make it work.
.gradient {
  --rotation: calc(90deg - var(--angle));
  background: conic-gradient(from var(--rotation), #84a59d 180deg, #f28482 180deg);
}
CodePen Embed Fallback
You may be wondering: can’t we do that with a linear gradient? And the answer is, yes! But this was just an example to showcase atan(). Let’s move on to more interesting stuff that’s unique to conic gradients.
I got the next example from Ana Tudor’s post on “Variable Aspect Ratio Card With Conic Gradients”:
CodePen Embed Fallback
Pretty cool, right?. Sadly, Ana’s post is from 2021, a time when trigonometric functions were specced out but not implemented. As she mentions in her article, it wasn’t possible to create these gradients using atan(). Luckily, we live in the future! Let’s see how simple they become with trigonometry and CSS.
We’ll use two conic gradients, each of them covering half of the card’s background.




To save time, I’ll gloss over exactly how to make the original gradient, so here is a quick little step-by-step guide on how to make one of those gradients in a square-shaped element:
CodePen Embed Fallback
Since we’re working with a perfect square, we can fix the --angle and --rotation to be 45deg, but for a general use case, each of the conic-gradients would look like this in CSS:
.gradient {
  background: 
    /* one below */
    conic-gradient(
      from var(--rotation) at bottom left,
      #b9eee1 calc(var(--angle) * 1 / 3),
      #79d3be calc(var(--angle) * 1 / 3) calc(var(--angle) * 2 / 3),
      #39b89a calc(var(--angle) * 2 / 3) calc(var(--angle) * 3 / 3),
      transparent var(--angle)
    ),
    /* one above */
    conic-gradient(
      from calc(var(--rotation) + 180deg) at top right,
      #fec9d7 calc(var(--angle) * 1 / 3),
      #ff91ad calc(var(--angle) * 1 / 3) calc(var(--angle) * 2 / 3),
      #ff5883 calc(var(--angle) * 2 / 3) calc(var(--angle) * 3 / 3),
      transparent var(--angle)
    );
}
And we can get those --angle and --rotation variables the same way we did earlier — using atan(), of course!
.gradient {
  --angle: atan(var(--height-gradient) / var(--width-gradient));
  --rotation: calc(90deg - var(--angle));
}
CodePen Embed Fallback
What about atan2()?
The last example was all abou atan(), but I told you we would also look at the atan2() function. With atan(), we get the angle when we divide the opposite side by the adjacent side and pass that value as the argument. On the flip side, atan2() takes them as separate arguments:
atan(opposite/adjacent)
atan2(opposite, adjacent)
What’s the difference? To explain, let’s backtrack a bit.
We used atan() in the context of triangles, meaning that the adjacent and opposite sides were always positive. This may seem like an obvious thing since lengths are always positive, but we won’t always work with lengths.
Imagine we are in a x-y plane and pick a random point on the graph. Just by looking at its position, we can know its x and y coordinates, which can have both negative and positive coordinates. What if we wanted its angle instead? Measuring it, of course, from the positive x-axis.




Well, remember from the last article in this series that we can also define tan() as the quotient between sin() and cos():




Also recall that when we measure the angle from the positive x-axis, then sin() returns the y-coordinate and cos() returns the x-coordinate. So, the last formula becomes:




And applying atan(), we can directly get the angle!




This formula has one problem, though. It should work for any point in the x-y plane, and since both x and y can be negative, we can confuse some points. Since we are dividing the y-coordinate by the x-coordinate, in the eyes of atan(), the negative y-coordinate looks the same as the negative x-coordinate. And if both coordinates are negative, it would look the same as if both were positive.




To compensate for this, we have atan2(), and since it takes the y-coordinate and x-coordinate as separate arguments, it’s smart enough to return the angle everywhere in the plane!
Let’s see how we can put it to practical use.
Following the mouse
Using atan2(), we can make elements react to the mouse’s position. Why would we want to do that? Meet my friend Helpy, Clippy’s uglier brother from Microsoft.
CodePen Embed Fallback
Helpy wants to always be looking at the user’s mouse, and luckily, we can help him using atan2(). I won’t go into too much detail about how Helpy is made, just know that his eyes are two pseudo-elements:
.helpy::before,
.helpy::after {
  /* eye styling */
}
To help Helpy, we first need to let CSS know the mouse’s current x-y coordinates. And while I may not like using JavaScript here, it’s needed in order to pass the mouse coordinates to CSS as two custom properties that we’ll call --m-x and --m-y.
const body = document.querySelector("body");

// listen for the mouse pointer
body.addEventListener("pointermove", (event) => {
  // set variables for the pointer's current coordinates
  let x = event.clientX;
  let y = event.clientY;

  // assign those coordinates to CSS custom properties in pixel units
  body.style.setProperty("--m-x", `${Math.round(x)}px`);
  body.style.setProperty("--m-y", `${Math.round(y)}px`);
});
Helpy is currently looking away from the content, so we’ll first move his eyes so they align with the positive x-axis, i.e., to the right.
.helpy::before,
.helpy::after {
  rotate: 135deg;
}
Once there, we can use atan2() to find the exact angle Helpy has to turn so he sees the user’s mouse. Since Helpy is positioned at the top-left corner of the page, and the x and y coordinates are measured from there, it’s time to plug those coordinates into our function: atan2(var(--m-y), var(--m-x)).
.helpy::before,
.helpy::after {
  /* rotate the eyes by it's starting position, plus the atan2 of the coordinates */
  rotate: calc(135deg + atan2(var(--m-y), var(--m-x)));
}
We can make one last improvement. You’ll notice that if the mouse goes on the little gap behind Helpy, he is unable to look at the pointer. This happens because we are measuring the coordinates exactly from the top-left corner, and Helpy is positioned a little bit away from that.
To fix this, we can translate the origin of the coordinate system directly on Helpy by subtracting the padding and half its size:




Which looks like this in CSS:
.helpy::before,
.helpy::after  {
  rotate: calc(
    135deg +
      atan2(
        var(--m-y) - var(--spacing) - var(--helpy-size) / 2,
        var(--m-x) - var(--spacing) - var(--helpy-size) / 2
      )
  );
}
CodePen Embed Fallback
This is a somewhat minor improvement, but moving the coordinate origin will be vital if we want to place Helpy in any other place on the screen.
Extra: Getting the viewport (and anything) in numbers
I can’t finish this series without mentioning a trick to typecast different units into simple numbers using atan2() and tan(). It isn’t directly related to trigonometry but it’s still super useful. It was first described amazingly by Jane Ori in 2023, and goes as follows.
If we want to get the viewport as an integer, then we can…
@property --100vw {
  syntax: "<length>;";
  initial-value: 0px;
  inherits: false;
}

:root {
  --100vw: 100vw;
  --int-width: calc(10000 * tan(atan2(var(--100vw), 10000px)));
}
And now: the --int-width variable holds the viewport width as an integer. This looks like magic, so I really recommend reading Jane Ori’s post to understand it. I also have an article using it to create animations as the viewport is resized!
CodePen Embed Fallback
What about reciprocals?
I noticed that we are still lacking the reciprocals for each trigonometric function. The reciprocals are merely 1 divided by the function, so there’s a total of three of them:
The secant, or sec(x), is the reciprocal of cos(x), so it’s 1 / cos(x).
The cosecant, or csc(x), is the reciprocal of sin(x), so it’s 1 / sin(x).
The cotangent, or cot(x) is the reciprocal of tan(x), so it’s 1 / tan(x).
The beauty of sin(), cos() and tan() and their reciprocals is that they all live in the unit circle we’ve looked at in other articles in this series. I decided to put everything together in the following demo that shows all of the trigonometric functions covered on the same unit circle:
CodePen Embed Fallback
That’s it!
Welp, that’s it! I hope you learned and had fun with this series just as much as I enjoyed writing it. And thanks so much for those of you who have shared your own demos. I’ll be rounding them up in my Bluesky page.

CSS Trigonometric Functions: The “Most Hated” CSS Feature
sin() and cos() 
tan()
asin(), acos(), atan() and atan2() (You are here!)


The “Most Hated” CSS Feature: asin(), acos(), atan() and atan2() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

If we have a ratio that represents the sine, cosine or tangent of an angle, how can we get the original angle? This is where inverse trigonometric functions come in!
The “Most Hated” CSS Feature: asin(), acos(), atan() and atan2() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The “Most Hated” CSS Feature: asin(), acos(), atan() and atan2()

<p>The extremely new framework that caught lots of attention will continue as a personal project.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/quiet-ui-came-and-went-quiet-as-a-mouse/">Quiet UI Came and Went, Quiet as a Mouse</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>A few weeks ago, <a href="https://quietui.org/" rel="noopener">Quiet UI</a> made the rounds when it was released as an open source user interface library, built with JavaScript web components. I had the opportunity to check out the documentation and it seemed like a solid library. I&#8217;m always super excited to see more options for web components out in the wild.</p>



<p>Unfortunately, before we even had a chance to cover it here at CSS-Tricks, Quiet UI has disappeared. When visiting the Quiet UI website, there is a simple statement:</p>



<span id="more-390408"></span>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow"><h3 class="wp-block-heading" id="unavailable">Unavailable</h3>


<p>Quiet UI is no longer available to the general public. I will continue to maintain it as my personal creative outlet, but I am unable to release it to the world at this time.<br>Thanks for understanding. I&#8217;m really sorry for the inconvenience.</p>
</blockquote>



<p>The repository for Quiet UI is no longer available on <a href="https://github.com/quietui" rel="noopener">Quiet UI&#8217;s GitHub</a>, and its social accounts seem to have been removed as well.</p>



<p>The creator, <a href="https://www.abeautifulsite.net/" rel="noopener">Cory LaViska</a>, is a veteran of UI libraries and most known for work on <a href="https://shoelace.style/" rel="noopener">Shoelace</a>. Shoelace <a href="https://blog.fontawesome.com/introducing-web-awesome/" rel="noopener">joined Font Awesome in 2022</a> and was rebranded as <a href="https://webawesome.com/" rel="noopener">Web Awesome</a>. The latest version of Web Awesome was released around the same time Quiet UI was originally announced.</p>



<p>According to the Quiet UI site, Cory will be continuing to work on it as a personal creative outlet, but hopefully we&#8217;ll be able to see what he&#8217;s cooking up again, someday. In the meantime, you can get a really good taste of what the project is/was all about in <a href="https://daverupert.com/2025/10/quiet-ui/" rel="noopener">Dave Rupert&#8217;s fantastic write-up</a>.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/quiet-ui-came-and-went-quiet-as-a-mouse/">Quiet UI Came and Went, Quiet as a Mouse</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


A few weeks ago, Quiet UI made the rounds when it was released as an open source user interface library, built with JavaScript web components. I had the opportunity to check out the documentation and it seemed like a solid library. I’m always super excited to see more options for web components out in the wild.
Unfortunately, before we even had a chance to cover it here at CSS-Tricks, Quiet UI has disappeared. When visiting the Quiet UI website, there is a simple statement:





Unavailable
Quiet UI is no longer available to the general public. I will continue to maintain it as my personal creative outlet, but I am unable to release it to the world at this time.
Thanks for understanding. I’m really sorry for the inconvenience.
The repository for Quiet UI is no longer available on Quiet UI’s GitHub, and its social accounts seem to have been removed as well.
The creator, Cory LaViska, is a veteran of UI libraries and most known for work on Shoelace. Shoelace joined Font Awesome in 2022 and was rebranded as Web Awesome. The latest version of Web Awesome was released around the same time Quiet UI was originally announced.
According to the Quiet UI site, Cory will be continuing to work on it as a personal creative outlet, but hopefully we’ll be able to see what he’s cooking up again, someday. In the meantime, you can get a really good taste of what the project is/was all about in Dave Rupert’s fantastic write-up.
Quiet UI Came and Went, Quiet as a Mouse originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The extremely new framework that caught lots of attention will continue as a personal project.
Quiet UI Came and Went, Quiet as a Mouse originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Quiet UI Came and Went, Quiet as a Mouse

<p>Being able to use the range syntax with container style queries — which we can do starting with Chrome 142 — means that we can compare literal numeric values as well as numeric values tokenized by custom properties or the <code>attr()</code> function.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/the-range-syntax-has-come-to-container-style-queries-and-if/">The Range Syntax Has Come to Container Style Queries and if()</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>



<p>The range syntax isn’t a new thing. <a href="https://css-tricks.com/the-new-css-media-query-range-syntax/">We‘re already able to use it with media queries</a> to query viewport dimensions and resolutions, as well as container <em>size</em> queries to query container dimensions. Being able to use it with container <em>style</em> queries — which we can do starting with Chrome 142 — means that we can compare literal numeric values as well as numeric values tokenized by custom properties or the <a href="https://css-tricks.com/almanac/functions/a/attr/"><code>attr()</code></a> function.</p>



<p>In addition, this feature comes to the <a href="https://css-tricks.com/if-css-gets-inline-conditionals/"><code>if()</code></a> function as well.</p>



<span id="more-390178"></span>



<p>Here’s a quick demo that shows the range syntax being used in both contexts to compare a custom property (<code>--lightness</code>) to a literal value (<code>50%</code>):</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#container {
  /* Choose any value 0-100% */
  --lightness: 10%;

  /* Applies it to the background */
  background: hsl(270 100% var(--lightness));

  color: if(
    /* If --lightness is less than 50%, white text */
    style(--lightness &lt; 50%): white;
    /* If --lightness is more than or equal to 50%, black text */
    style(--lightness >= 50%): black
  );

  /* Selects the children */
  * {
    /* Specifically queries parents */
    @container style(--lightness &lt; 50%) {
      color: white;
    }

    @container style(--lightness >= 50%) {
      color: black;
    }
  }
}</code></pre>



<p>Again, you’ll want Chrome 142 or higher to see this work:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_pvgpKJN" src="//codepen.io/anon/embed/pvgpKJN?height=450&amp;theme-id=1&amp;slug-hash=pvgpKJN&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed pvgpKJN" title="CodePen Embed pvgpKJN" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>Both methods do the same thing but in slightly different ways.</p>



<p>Let’s take a closer look.</p>


<h3 class="wp-block-heading" id="range-syntax-with-custom-properties">Range syntax with custom properties</h3>


<p>In the next demo coming up, I’ve cut out the <code>if()</code> stuff, leaving only the container style queries. What’s happening here is that we’ve created a custom property called <code>--lightness</code> on the <code>#container</code>. Querying the value of an ordinary property isn’t possible, so instead we save it (or a part of it) as a custom property, and then use it to form the HSL-formatted value of the <code>background</code>.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#container {
  /* Choose any value 0-100% */
  --lightness: 10%;

  /* Applies it to the background */
  background: hsl(270 100% var(--lightness));
}</code></pre>



<p>After that we select the container’s children and conditionally declare their <code>color</code> using container style queries. Specifically, if the <code>--lightness</code> property of <code>#container</code> (and, by extension, the <code>background</code>) is less than <code>50%</code>, we set the <code>color</code> to <code>white</code>. Or, if it’s more than or equal to <code>50%</code>, we set the <code>color</code> to <code>black</code>.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#container {
  /* etc. */

  /* Selects the children */
  * {
    /* Specifically queries parents */
    @container style(--lightness &lt; 50%) {
      color: white;
    }

    @container style(--lightness >= 50%) {
      color: black;
    }
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_raxpXLO" src="//codepen.io/anon/embed/raxpXLO?height=450&amp;theme-id=1&amp;slug-hash=raxpXLO&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed raxpXLO" title="CodePen Embed raxpXLO" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>/explanation Note that we wouldn’t be able to move the <code>@container</code> at-rules to the <code>#container</code> block, because then we’d be querying <code>--lightness</code> on the container of <code>#container</code> (where it doesn’t exist) and then beyond (where it also doesn’t exist).</p>



<p>Prior to the range syntax coming to container style queries, we could only query specific values, so the range syntax makes container style queries much more useful.</p>



<p>By contrast, the <code>if()</code>-based declaration would work in either block:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#container {
  --lightness: 10%;
  background: hsl(270 100% var(--lightness));

  /* --lightness works here */
  color: if(
    style(--lightness &lt; 50%): white;
    style(--lightness >= 50%): black
  );

  * {
    /* And here! */
    color: if(
      style(--lightness &lt; 50%): white;
      style(--lightness >= 50%): black
    );
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_VYeQZLE" src="//codepen.io/anon/embed/VYeQZLE?height=450&amp;theme-id=1&amp;slug-hash=VYeQZLE&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed VYeQZLE" title="CodePen Embed VYeQZLE" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>So, given that container style queries only look <em>up</em> the cascade (whereas <code>if()</code> also looks for custom properties declared within the same CSS rule) why use container style queries at all? Well, personal preference aside, container queries allow us to define a specific containment context using the <a href="https://css-tricks.com/almanac/properties/c/container-name/"><code>container-name</code></a> CSS property:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line="6"><code markup="tt">#container {
  --lightness: 10%;
  background: hsl(270 100% var(--lightness));

  /* Define a named containment context */
  container-name: myContainer;

  * {
    /* Specify the name here */
    @container myContainer style(--lightness &lt; 50%) {
      color: white;
    }

    @container myContainer style(--lightness >= 50%) {
      color: black;
    }
  }
}</code></pre>



<p>With this version, if the <a href="https://css-tricks.com/almanac/rules/c/container/"><code>@container</code></a> at-rule can’t find <code>--lightness</code> on <code>myContainer</code>, the block doesn’t run. If we wanted <code>@container</code> to look further up the cascade, we’d only need to declare <code>container-name: myContainer</code> further up the cascade. The <code>if()</code> function doesn’t allow for this, but container queries allow us to control the scope.</p>


<h3 class="wp-block-heading" id="range-syntax-with-the-attr-css-function">Range syntax with the <code>attr()</code> CSS function</h3>


<p>We can also pull values from HTML attributes using the <a href="https://css-tricks.com/almanac/functions/a/attr/"><code>attr()</code></a> CSS function.</p>



<p>In the HTML below, I’ve created an element with a data attribute called <code>data-notifs</code> whose value represents the number of unread notifications that a user has:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;div data-notifs="8">&lt;/div></code></pre>



<p>We want to select <code>[data-notifs]::after</code> so that we can place the number inside <code>[data-notifs]</code> using the <a href="https://css-tricks.com/almanac/properties/c/content/"><code>content</code></a> CSS property. In turn, this is where we’ll put the <code>@container</code> at-rules, with <code>[data-notifs]</code> serving as the container. I’ve also included a <code>height</code> and matching <code>border-radius</code> for styling:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">[data-notifs]::after {
  height: 1.25rem;
  border-radius: 1.25rem;

  /* Container style queries here */
}</code></pre>



<p>Now for the container style query logic. In the first one, it’s fairly obvious that if the notification count is 1-2 digits (or, as it’s expressed in the query, less than or equal to 99), then <code>content: attr(data-notifs)</code> inserts the number from the <code>data-notifs</code> attribute while <code>aspect-ratio: 1 / 1</code> ensures that the width matches the height, forming a circular notification badge.</p>



<p>In the second query, which matches if the number is more than <code>99</code>, we switch to <code>content: "99+"</code> because I don’t think that a notification badge could handle four digits. We also include some inline padding instead of a <code>width</code>, since not even three characters can fit into the circle.</p>



<p>To summarize, we’re basically using this container style query logic to determine both content and style, which is really cool:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">[data-notifs]::after {
  height: 1.25rem;
  border-radius: 1.25rem;

  /* If notification count is 1-2 digits */
  @container style(attr(data-notifs type(&lt;number>)) &lt;= 99) {

    /* Display count */
    content: attr(data-notifs);

    /* Make width equal the height */
    aspect-ratio: 1 / 1;
  }

  /* If notification count is 3 or more digits */
  @container style(attr(data-notifs type(&lt;number>)) > 99) {
    /* After 99, simply say "99+" */
    content: "99+";

    /* Instead of width, a little padding */
    padding-inline: 0.1875rem;
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_ogbqbjL" src="//codepen.io/anon/embed/ogbqbjL?height=450&amp;theme-id=1&amp;slug-hash=ogbqbjL&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed ogbqbjL" title="CodePen Embed ogbqbjL" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>



<p>But you’re likely wondering why, when we read the value in the container style queries, it’s written as <code>attr(data-notifs type(&lt;number&gt;)</code> instead of <code>attr(data-notifs)</code>. Well, the reason is that when we don’t specify a data type (or unit, you can read all about the <a href="https://css-tricks.com/almanac/functions/a/attr/">recent changes to <code>attr()</code> here</a>), the value is parsed as a string. This is fine when we’re outputting the value with <code>content: attr(data-notifs)</code>, but when we’re <em>comparing</em> it to <code>99</code>, we must parse it as a number (although <code>type(&lt;integer&gt;)</code> would also work).</p>



<p>In fact, all range syntax comparatives must be of the same data type (although they don’t have to use the same units). Supported data types include <code>&lt;length&gt;</code>, <code>&lt;number&gt;</code>, <code>&lt;percentage&gt;</code>, <code>&lt;angle&gt;</code>, <code>&lt;time&gt;</code>, <code>&lt;frequency&gt;</code>, and <code>&lt;resolution&gt;</code>. In the earlier example, we could actually express the lightness without units since the modern <code>hsl()</code> syntax supports that, but we’d have to be consistent with it and ensure that all comparatives are unit-less too:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#container {
  /* 10, not 10% */
  --lightness: 10;

  background: hsl(270 100 var(--lightness));

  color: if(
    /* 50, not 50% */
    style(--lightness &lt; 50): white;
    style(--lightness >= 50): black
  );

  * {
    /* 50, not 50% */
    @container style(--lightness &lt; 50) {
      color: white;
    }

    @container style(--lightness >= 50) {
      color: black;
    }
  }
}</code></pre>



<p class="is-style-explanation"><strong>Note:</strong> This notification count example doesn’t lend itself well to <code>if()</code>, as you’d need to include the logic for every relevant CSS property, but it is possible and would use the same logic.</p>


<h3 class="wp-block-heading" id="range-syntax-with-literal-values">Range syntax with literal values</h3>


<p>We can also compare literal values, for example, <code>1em</code> to <code>32px</code>. Yes, they’re different units, but remember, they only have to be the same data type and these are both valid <a href="https://css-tricks.com/css-length-units/">CSS <code>&lt;length></code>s</a>.</p>



<p>In the next example, we set the <code>font-size</code> of the <code>&lt;h1&gt;</code> element to <code>31px</code>. The <code>&lt;span&gt;</code> inherits this <code>font-size</code>, and since <code>1em</code> is equal to the <code>font-size</code> of the parent, <code>1em</code> in the scope of <code>&lt;span&gt;</code> is also <code>31px</code>. With me so far?</p>



<p>According to the <code>if()</code> logic, if <code>1em</code> is equal to less than <code>32px</code>, the <code>font-weight</code> is smaller (to be exaggerative, let’s say <code>100</code>), whereas if <code>1em</code> is equal to or greater than <code>32px</code>, we set the <code>font-weight</code> to a chunky <code>900</code>. If we remove the <code>font-size</code> declaration, then <code>1em</code> computes to the user agent default of <code>32px</code>, and <em>neither</em> condition matches, leaving the <code>font-weight</code> to also compute to the user agent default, which for all headings is <code>700</code>.</p>



<p>Basically, the idea is that if we mess with the default <code>font-size</code> of the <code>&lt;h1&gt;</code>, then we declare an optimized <code>font-weight</code> to maintain readability, preventing small-fat and large-thin text.</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;h1>
  &lt;span>Heading 1&lt;/span>
&lt;/h1></code></pre>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">h1 {
  /*
    The default value is 32px,
    but we overwrite it to 31px,
    causing the first if() condition to match
  */
  font-size: 31px;

  span {
    /* Here, 1em is equal to 31px */

    font-weight: if(
      style(1em &lt; 32px): 100;
      style(1em > 32px): 900
    );
  }
}</code></pre>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper"><iframe id="cp_embed_gbPzxmR" src="//codepen.io/anon/embed/gbPzxmR?height=450&amp;theme-id=1&amp;slug-hash=gbPzxmR&amp;default-tab=result" height="450" scrolling="no" frameborder="0" allowfullscreen allowpaymentrequest name="CodePen Embed gbPzxmR" title="CodePen Embed gbPzxmR" class="cp_embed_iframe" style="width:100%;overflow:hidden">CodePen Embed Fallback</iframe></div>


<h3 class="wp-block-heading" id="css-queries-have-come-a-long-way-haven-t-they-">CSS queries have come a long way, haven’t they?</h3>


<p>In my opinion, the range syntax coming to container style queries and the <code>if()</code> function represents CSS’s biggest leap in terms of conditional logic, especially considering that it can be combined with media queries, feature queries, and other types of container queries (remember to declare <code>container-type</code> if combining with container size queries). In fact, now would be a <em>great</em> time to freshen up on queries, so as a little parting gift, here are some links for further reading:</p>



<ul class="wp-block-list">
<li><a href="https://css-tricks.com/a-complete-guide-to-css-media-queries/">Media queries</a></li>



<li><a href="https://css-tricks.com/css-container-queries/">Container queries</a></li>



<li><a href="https://css-tricks.com/almanac/rules/s/supports/">Feature queries</a></li>
</ul>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/the-range-syntax-has-come-to-container-style-queries-and-if/">The Range Syntax Has Come to Container Style Queries and if()</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&amp;utm_source=css-tricks.com&amp;utm_campaign=family_&amp;utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>


The range syntax isn’t a new thing. We‘re already able to use it with media queries to query viewport dimensions and resolutions, as well as container size queries to query container dimensions. Being able to use it with container style queries — which we can do starting with Chrome 142 — means that we can compare literal numeric values as well as numeric values tokenized by custom properties or the attr() function.
In addition, this feature comes to the if() function as well.




Here’s a quick demo that shows the range syntax being used in both contexts to compare a custom property (--lightness) to a literal value (50%):
#container {
  /* Choose any value 0-100% */
  --lightness: 10%;

  /* Applies it to the background */
  background: hsl(270 100% var(--lightness));

  color: if(
    /* If --lightness is less than 50%, white text */
    style(--lightness < 50%): white;
    /* If --lightness is more than or equal to 50%, black text */
    style(--lightness >= 50%): black
  );

  /* Selects the children */
  * {
    /* Specifically queries parents */
    @container style(--lightness < 50%) {
      color: white;
    }

    @container style(--lightness >= 50%) {
      color: black;
    }
  }
}
Again, you’ll want Chrome 142 or higher to see this work:
CodePen Embed Fallback
Both methods do the same thing but in slightly different ways.
Let’s take a closer look.
Range syntax with custom properties
In the next demo coming up, I’ve cut out the if() stuff, leaving only the container style queries. What’s happening here is that we’ve created a custom property called --lightness on the #container. Querying the value of an ordinary property isn’t possible, so instead we save it (or a part of it) as a custom property, and then use it to form the HSL-formatted value of the background.
#container {
  /* Choose any value 0-100% */
  --lightness: 10%;

  /* Applies it to the background */
  background: hsl(270 100% var(--lightness));
}
After that we select the container’s children and conditionally declare their color using container style queries. Specifically, if the --lightness property of #container (and, by extension, the background) is less than 50%, we set the color to white. Or, if it’s more than or equal to 50%, we set the color to black.
#container {
  /* etc. */

  /* Selects the children */
  * {
    /* Specifically queries parents */
    @container style(--lightness < 50%) {
      color: white;
    }

    @container style(--lightness >= 50%) {
      color: black;
    }
  }
}
CodePen Embed Fallback
/explanation Note that we wouldn’t be able to move the @container at-rules to the #container block, because then we’d be querying --lightness on the container of #container (where it doesn’t exist) and then beyond (where it also doesn’t exist).
Prior to the range syntax coming to container style queries, we could only query specific values, so the range syntax makes container style queries much more useful.
By contrast, the if()-based declaration would work in either block:
#container {
  --lightness: 10%;
  background: hsl(270 100% var(--lightness));

  /* --lightness works here */
  color: if(
    style(--lightness < 50%): white;
    style(--lightness >= 50%): black
  );

  * {
    /* And here! */
    color: if(
      style(--lightness < 50%): white;
      style(--lightness >= 50%): black
    );
  }
}
CodePen Embed Fallback
So, given that container style queries only look up the cascade (whereas if() also looks for custom properties declared within the same CSS rule) why use container style queries at all? Well, personal preference aside, container queries allow us to define a specific containment context using the container-name CSS property:
#container {
  --lightness: 10%;
  background: hsl(270 100% var(--lightness));

  /* Define a named containment context */
  container-name: myContainer;

  * {
    /* Specify the name here */
    @container myContainer style(--lightness < 50%) {
      color: white;
    }

    @container myContainer style(--lightness >= 50%) {
      color: black;
    }
  }
}
With this version, if the @container at-rule can’t find --lightness on myContainer, the block doesn’t run. If we wanted @container to look further up the cascade, we’d only need to declare container-name: myContainer further up the cascade. The if() function doesn’t allow for this, but container queries allow us to control the scope.
Range syntax with the attr() CSS function
We can also pull values from HTML attributes using the attr() CSS function.
In the HTML below, I’ve created an element with a data attribute called data-notifs whose value represents the number of unread notifications that a user has:
<div data-notifs="8"></div>
We want to select [data-notifs]::after so that we can place the number inside [data-notifs] using the content CSS property. In turn, this is where we’ll put the @container at-rules, with [data-notifs] serving as the container. I’ve also included a height and matching border-radius for styling:
[data-notifs]::after {
  height: 1.25rem;
  border-radius: 1.25rem;

  /* Container style queries here */
}
Now for the container style query logic. In the first one, it’s fairly obvious that if the notification count is 1-2 digits (or, as it’s expressed in the query, less than or equal to 99), then content: attr(data-notifs) inserts the number from the data-notifs attribute while aspect-ratio: 1 / 1 ensures that the width matches the height, forming a circular notification badge.
In the second query, which matches if the number is more than 99, we switch to content: "99+" because I don’t think that a notification badge could handle four digits. We also include some inline padding instead of a width, since not even three characters can fit into the circle.
To summarize, we’re basically using this container style query logic to determine both content and style, which is really cool:
[data-notifs]::after {
  height: 1.25rem;
  border-radius: 1.25rem;

  /* If notification count is 1-2 digits */
  @container style(attr(data-notifs type(<number>)) <= 99) {

    /* Display count */
    content: attr(data-notifs);

    /* Make width equal the height */
    aspect-ratio: 1 / 1;
  }

  /* If notification count is 3 or more digits */
  @container style(attr(data-notifs type(<number>)) > 99) {
    /* After 99, simply say "99+" */
    content: "99+";

    /* Instead of width, a little padding */
    padding-inline: 0.1875rem;
  }
}
CodePen Embed Fallback
But you’re likely wondering why, when we read the value in the container style queries, it’s written as attr(data-notifs type(<number>) instead of attr(data-notifs). Well, the reason is that when we don’t specify a data type (or unit, you can read all about the recent changes to attr() here), the value is parsed as a string. This is fine when we’re outputting the value with content: attr(data-notifs), but when we’re comparing it to 99, we must parse it as a number (although type(<integer>) would also work).
In fact, all range syntax comparatives must be of the same data type (although they don’t have to use the same units). Supported data types include <length>, <number>, <percentage>, <angle>, <time>, <frequency>, and <resolution>. In the earlier example, we could actually express the lightness without units since the modern hsl() syntax supports that, but we’d have to be consistent with it and ensure that all comparatives are unit-less too:
#container {
  /* 10, not 10% */
  --lightness: 10;

  background: hsl(270 100 var(--lightness));

  color: if(
    /* 50, not 50% */
    style(--lightness < 50): white;
    style(--lightness >= 50): black
  );

  * {
    /* 50, not 50% */
    @container style(--lightness < 50) {
      color: white;
    }

    @container style(--lightness >= 50) {
      color: black;
    }
  }
}
Note: This notification count example doesn’t lend itself well to if(), as you’d need to include the logic for every relevant CSS property, but it is possible and would use the same logic.
Range syntax with literal values
We can also compare literal values, for example, 1em to 32px. Yes, they’re different units, but remember, they only have to be the same data type and these are both valid CSS <length>s.
In the next example, we set the font-size of the <h1> element to 31px. The <span> inherits this font-size, and since 1em is equal to the font-size of the parent, 1em in the scope of <span> is also 31px. With me so far?
According to the if() logic, if 1em is equal to less than 32px, the font-weight is smaller (to be exaggerative, let’s say 100), whereas if 1em is equal to or greater than 32px, we set the font-weight to a chunky 900. If we remove the font-size declaration, then 1em computes to the user agent default of 32px, and neither condition matches, leaving the font-weight to also compute to the user agent default, which for all headings is 700.
Basically, the idea is that if we mess with the default font-size of the <h1>, then we declare an optimized font-weight to maintain readability, preventing small-fat and large-thin text.
<h1>
  <span>Heading 1</span>
</h1>
h1 {
  /*
    The default value is 32px,
    but we overwrite it to 31px,
    causing the first if() condition to match
  */
  font-size: 31px;

  span {
    /* Here, 1em is equal to 31px */

    font-weight: if(
      style(1em < 32px): 100;
      style(1em > 32px): 900
    );
  }
}
CodePen Embed Fallback
CSS queries have come a long way, haven’t they?
In my opinion, the range syntax coming to container style queries and the if() function represents CSS’s biggest leap in terms of conditional logic, especially considering that it can be combined with media queries, feature queries, and other types of container queries (remember to declare container-type if combining with container size queries). In fact, now would be a great time to freshen up on queries, so as a little parting gift, here are some links for further reading:
Media queries
Container queries
Feature queries
The Range Syntax Has Come to Container Style Queries and if() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Being able to use the range syntax with container style queries — which we can do starting with Chrome 142 — means that we can compare literal numeric values as well as numeric values tokenized by custom properties or the attr() function.
The Range Syntax Has Come to Container Style Queries and if() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.