CSS-TRICKS

<p>Well, it turns out that SVG's built-in animation features were never deprecated as planned. Sure, CSS and JavaScript are more than capable of carrying the load, but it's good to know that SMIL is not dead in the water as previously thought, and is actually well-supported.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/smil-on/">SMIL on?</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 was chatting with <a href="https://css-tricks.com/author/andyclarke/">Andy Clarke</a> the other day about a new article he wants to write about SVG animations.</p>



<p>&#8220;I’ve read some things that said that&nbsp;SMIL might be a dead end.&#8221; He said. &#8220;Whaddya think?&#8221;</p>



<p>That was my impression, too. <a href="https://css-tricks.com/smil-is-dead-long-live-smil-a-guide-to-alternatives-to-smil-features/">Sarah Drasner summed up the situation</a> nicely way back in 2017:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Unfortunately, support for SMIL is waning in WebKit, and has never (nor will likely ever) exist for Microsoft’s IE or Edge browsers.&nbsp;</p>
</blockquote>



<p>Chrome was also in on the party and <a href="https://groups.google.com/a/chromium.org/g/blink-dev/c/5o0yiO440LM/m/pCYlMnmYAAAJ" rel="noopener">published an intent to deprecate SMIL</a>, citing work in other browsers to support SVG animations in CSS. MDN linked to that same thread in its SMIL documentation when it published a deprecation warning.</p>



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



<p>Well, Chrome never deprecated SMIL. At least according to <a href="https://groups.google.com/a/chromium.org/g/blink-dev/c/5o0yiO440LM/m/pCYlMnmYAAAJ" rel="noopener">this reply in the thread</a> dated 2023. And since then, we&#8217;ve also seen Microsoft&#8217;s Edge adopt a Chromium engine, effectively making it a Chrome clone. Also, last I checked, <a href="https://caniuse.com/svg-smil" rel="noopener">Caniuse reports full support in WebKit browsers</a>. </p>


<div class="caniuse"><div class="caniuse-header"><p>This browser support data is from <a href="http://caniuse.com/#feat=svg-smil" rel="noopener">Caniuse</a>, which has more detail. A number indicates that browser supports the feature at that version and up.</p></div><div class="caniuse-section"><h4>Desktop</h4><table class="browser-support-table"><thead><tr><th class="chrome"><span>Chrome</span></th><th class="firefox"><span>Firefox</span></th><th class="ie"><span>IE</span></th><th class="edge"><span>Edge</span></th><th class="safari"><span>Safari</span></th></tr></thead><tbody><tr><td class="y yep" title="Chrome - "><span class="caniuse-agents-version version">5</span></td><td class="y yep" title="Firefox - "><span class="caniuse-agents-version version">4</span></td><td class="p yep-nope yep-nope-polyfill" title="IE - "><span class="caniuse-agents-version version">11</span></td><td class="y yep" title="Edge - "><span class="caniuse-agents-version version">79</span></td><td class="y yep" title="Safari - "><span class="caniuse-agents-version version">6</span></td></tr></table></div><div class="caniuse-section"><h4>Mobile / Tablet</h4><table class="browser-support-table"><thead><tr><th class="and_chr"><span>Android Chrome</span></th><th class="and_ff"><span>Android Firefox</span></th><th class="android"><span>Android</span></th><th class="ios_saf"><span>iOS Safari</span></th></tr></thead><tbody><tr><td class="y yep" title="Android Chrome - "><span class="caniuse-agents-version version">134</span></td><td class="y yep" title="Android Firefox - "><span class="caniuse-agents-version version">136</span></td><td class="y yep" title="Android - "><span class="caniuse-agents-version version">3</span></td><td class="y yep" title="iOS Safari - "><span class="caniuse-agents-version version">6.0-6.1</span></td></tr></table></div></div>



<p>Now, I&#8217;m not saying that SMIL is perfectly alive and well. It could still very well be in the doldrums, especially when there are robust alternatives in CSS and JavaScript. But it&#8217;s also not dead in the water.</p>



<p></p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/smil-on/">SMIL on?</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 was chatting with Andy Clarke the other day about a new article he wants to write about SVG animations.
“I’ve read some things that said that SMIL might be a dead end.” He said. “Whaddya think?”
That was my impression, too. Sarah Drasner summed up the situation nicely way back in 2017:
Unfortunately, support for SMIL is waning in WebKit, and has never (nor will likely ever) exist for Microsoft’s IE or Edge browsers. 
Chrome was also in on the party and published an intent to deprecate SMIL, citing work in other browsers to support SVG animations in CSS. MDN linked to that same thread in its SMIL documentation when it published a deprecation warning.




Well, Chrome never deprecated SMIL. At least according to this reply in the thread dated 2023. And since then, we’ve also seen Microsoft’s Edge adopt a Chromium engine, effectively making it a Chrome clone. Also, last I checked, Caniuse reports full support in WebKit browsers. 

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

ChromeFirefoxIEEdgeSafari

5411796


Mobile / Tablet

Android ChromeAndroid FirefoxAndroidiOS Safari

13413636.0-6.1





Now, I’m not saying that SMIL is perfectly alive and well. It could still very well be in the doldrums, especially when there are robust alternatives in CSS and JavaScript. But it’s also not dead in the water.


SMIL on? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Well, it turns out that SVG's built-in animation features were never deprecated as planned. Sure, CSS and JavaScript are more than capable of carrying the load, but it's good to know that SMIL is not dead in the water as previously thought, and is actually well-supported.
SMIL on? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

SMIL on?

<p>One thing we can do to help teams code consistently is provide type-checking so that all of the configurable options for a specific component are available while coding. Bryan demonstrates how he does this with TypeScript when working with Astro components.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/crafting-strong-dx-with-astro-components-and-typescript/">Crafting Strong DX With Astro Components and TypeScript</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’m a big fan of Astro’s focus on developer experience (DX) and the onboarding of new developers. While the basic DX is strong, I can easily make a convoluted system that is hard to onboard my own developers to. I don’t want that to happen.
If I have multiple developers working on a project, I want them to know exactly what to expect from every component that they have at their disposal. This goes double for myself in the future when I’ve forgotten how to work with my own system!
To do that, a developer could go read each component and get a strong grasp of it before using one, but that feels like the onboarding would be incredibly slow. A better way would be to set up the interface so that as the developer is using the component, they have the right knowledge immediately available. Beyond that, it would bake in some defaults that don’t allow developers to make costly mistakes and alerts them to what those mistakes are before pushing code!
Enter, of course, TypeScript. Astro comes with TypeScript set up out of the box. You don’t have to use it, but since it’s there, let’s talk about how to use it to craft a stronger DX for our development teams.



Watch
I’ve also recorded a video version of this article that you can watch if that’s your jam. Check it out on YouTube for chapters and closed captioning.



Setup
In this demo, we’re going to use a basic Astro project. To get this started, run the following command in your terminal and choose the “Minimal” template.
npm create astro@latest
This will create a project with an index route and a very simple “Welcome” component. For clarity, I recommend removing the <Welcome /> component from the route to have a clean starting point for your project.
To add a bit of design, I’d recommend setting up Tailwind for Astro (though, you’re welcome to style your component however you would like including a style block in the component).
npx astro add tailwind
Once this is complete, you’re ready to write your first component.
Creating the basic Heading component
Let’s start by defining exactly what options we want to provide in our developer experience.
For this component, we want to let developers choose from any HTML heading level (H1-H6). We also want them to be able to choose a specific font size and font weight — it may seem obvious now, but we don’t want people choosing a specific heading level for the weight and font size, so we separate those concerns.
Finally, we want to make sure that any additional HTML attributes can be passed through to our component. There are few things worse than having a component and then not being able to do basic functionality later.
Using Dynamic tags to create the HTML element
Let’s start by creating a simple component that allows the user to dynamically choose the HTML element they want to use. Create a new component at ./src/components/Heading.astro.
---
// ./src/component/Heading.astro
const { as } = Astro.props;
const As = as;
---

<As>
  <slot />
</As>
To use a prop as a dynamic element name, we need the variable to start with a capital letter. We can define this as part of our naming convention and make the developer always capitalize this prop in their use, but that feels inconsistent with how most naming works within props. Instead, let’s keep our focus on the DX, and take that burden on for ourselves.
In order to dynamically register an HTML element in our component, the variable must start with a capital letter. We can convert that in the frontmatter of our component. We then wrap all the children of our component in the <As> component by using Astro’s built-in <slot /> component.
Now, we can use this component in our index route and render any HTML element we want. Import the component at the top of the file, and then add <h1> and <h2> elements to the route.
---
// ./src/pages/index.astro
import Layout from '../layouts/Layout.astro';
import Heading from '../components/Heading.astro';

---

<Layout>
  <Heading as="h1">Hello!</Heading>
  <Heading as="h2">Hello world</Heading>
</Layout>




This will render them correctly on the page and is a great start.
Adding more custom props as a developer interface
Let’s clean up the element choosing by bringing it inline to our props destructuring, and then add in additional props for weight, size, and any additional HTML attributes.
To start, let’s bring the custom element selector into the destructuring of the Astro.props object. At the same time, let’s set a sensible default so that if a developer forgets to pass this prop, they still will get a heading.
---
// ./src/component/Heading.astro
const { as: As="h2" } = Astro.props;
---

<As>
  <slot />
</As>

Next, we’ll get weight and size. Here’s our next design choice for our component system: do we make our developers know the class names they need to use or do we provide a generic set of sizes and do the mapping ourselves? Since we’re building a system, I think it’s important to move away from class names and into a more declarative setup. This will also future-proof our system by allowing us to change out the underlying styling and class system without affecting the DX.
Not only do we future proof it, but we also are able to get around a limitation of Tailwind by doing this. Tailwind, as it turns out can’t handle dynamically-created class strings, so by mapping them, we solve an immediate issue as well.
In this case, our sizes will go from small (sm) to six times the size (6xl) and our weights will go from “light” to “bold”.
Let’s start by adjusting our frontmatter. We need to get these props off the Astro.props object and create a couple objects that we can use to map our interface to the proper class structure.
---
// ./src/component/Heading.astro

const weights = {
    "bold": "font-bold",
    "semibold": "font-semibold",
    "medium": "font-medium",
    "light": "font-light"
}
const sizes= {
    "6xl": "text-6xl",
    "5xl": "text-5xl",
    "4xl": "text-4xl",
    "3xl": "text-3xl",
    "2xl": "text-2xl",
    "xl": "text-xl",
    "lg": "text-lg",
    "md": "text-md",
    "sm": "text-sm"
}

const { as: As="h2", weight="medium", size="2xl" } = Astro.props;
---
Depending on your use case, this amount of sizes and weights might be overkill. The great thing about crafting your own component system is that you get to choose and the only limitations are the ones you set for yourself.
From here, we can then set the classes on our component. While we could add them in a standard class attribute, I find using Astro’s built-in class:list directive to be the cleaner way to programmatically set classes in a component like this. The directive takes an array of classes that can be strings, arrays themselves, objects, or variables. In this case, we’ll select the correct size and weight from our map objects in the frontmatter.
---
// ./src/component/Heading.astro

const weights = {
  bold: "font-bold",
  semibold: "font-semibold",
  medium: "font-medium",
  light: "font-light",
};
const sizes = {
  "6xl": "text-6xl",
  "5xl": "text-5xl",
  "4xl": "text-4xl",
  "3xl": "text-3xl",
  "2xl": "text-2xl",
  xl: "text-xl",
  lg: "text-lg",
  md: "text-md",
  sm: "text-sm",
};

const { as: As = "h2", weight = "medium", size = "2xl" } = Astro.props;
---

<As class:list={[
  sizes[size], 
  weights[weight]
]}
>
  <slot />
</As>

Your front-end should automatically shift a little in this update. Now your font weight will be slightly thicker and the classes should be applied in your developer tools.




From here, add the props to your index route, and find the right configuration for your app.
---
// ./src/pages/index.astro
import Layout from '../layouts/Layout.astro';
import Heading from '../components/Heading.astro';
---

<Layout>
  <Heading as="h1" size="6xl" weight="light">Hello!</Heading>
  <Heading as="h3" size="xl" weight="bold">Hello world</Heading>
</Layout>




Our custom props are finished, but currently, we can’t use any default HTML attributes, so let’s fix that.
Adding HTML attributes to the component
We don’t know what sorts of attributes our developers will want to add, so let’s make sure they can add any additional ones they need.
To do that, we can spread any other prop being passed to our component, and then add them to the rendered component.
---
// ./src/component/Heading.astro

const weights = {
  // etc.
};
const sizes = {
  // etc.
};

const { as: As = "h2", weight = "medium", size = "md", ...attrs } = Astro.props;
---

<As class:list={[
  sizes[size], 
  weights[weight]
]}
{...attrs}
>
  <slot />
</As>
From here, we can add any arbitrary attributes to our element.
---
// ./src/pages/index.astro
import Layout from '../layouts/Layout.astro';
import Heading from '../components/Heading.astro';

---

<Layout>
  <Heading id="my-id" as="h1" size="6xl" weight="light">Hello!</Heading>
  <Heading class="text-blue-500" as="h3" size="xl" weight="bold">Hello world</Heading>
</Layout>
I’d like to take a moment to truly appreciate one aspect of this code. Our <h1>, we add an id attribute. No big deal. Our <h3>, though, we’re adding an additional class. My original assumption when creating this was that this would conflict with the class:list set in our component. Astro takes that worry away. When the class is passed and added to the component, Astro knows to merge the class prop with the class:list directive and automatically makes it work. One less line of code!




In many ways, I like to consider these additional attributes as “escape hatches” in our component library. Sure, we want our developers to use our tools exactly as intended, but sometimes, it’s important to add new attributes or push our design system’s boundaries. For this, we allow them to add their own attributes, and it can create a powerful mix.
It looks done, but are we?
At this point, if you’re following along, it might feel like we’re done, but we have two issues with our code right now: (1) our component has “red squiggles” in our code editor and (2) our developers can make a BIG mistake if they choose.
The red squiggles come from type errors in our component. Astro gives us TypeScript and linting by default, and sizes and weights can’t be of type: any. Not a big deal, but concerning depending on your deployment settings.
The other issue is that our developers don’t have to choose a heading element for their heading. I’m all for escape hatches, but only if they don’t break the accessibility and SEO of my site.
Imagine, if a developer used this with a div instead of an h1 on the page. What would happen?We don’t have to imagine, make the change and see.




It looks identical, but now there’s no <h1> element on the page. Our semantic structure is broken, and that’s bad news for many reasons. Let’s use typing to help our developers make the best decisions and know what options are available for each prop.
Adding types to the component
To set up our types, first we want to make sure we handle any HTML attributes that come through. Astro, again, has our backs and has the typing we need to make this work. We can import the right HTML attribute types from Astro’s typing package. Import the type and then we can extend that type for our own props. In our example, we’ll select the h1 types, since that should cover most anything we need for our headings.
Inside the Props interface, we’ll also add our first custom type. We’ll specify that the as prop must be one of a set of strings, instead of just a basic string type. In this case, we want it to be h1–h6 and nothing else.
---
// ./src/component/Heading.astro
import type { HTMLAttributes } from 'astro/types';

interface Props extends HTMLAttributes<'h1'> {
  as: "h1" | "h2" | "h3" | "h4" | "h5" | "h6";
}

//... The rest of the file
---
After adding this, you’ll note that in your index route, the <h1> component should now have a red underline for the as="div" property. When you hover over it, it will let you know that the as type does not allow for div and it will show you a list of acceptable strings.
If you delete the div, you should also now have the ability to see a list of what’s available as you try to add the string.




While it’s not a big deal for the element selection, knowing what’s available is a much bigger deal to the rest of the props, since those are much more custom.
Let’s extend the custom typing to show all the available options. We also denote these items as optional by using the ?:before defining the type.
While we could define each of these with the same type functionality as our as type, that doesn’t keep this future proofed. If we add a new size or weight, we’d have to make sure to update our type. To solve this, we can use a fun trick in TypeScript: keyof typeof.
There are two helper functions in TypeScript that will help us convert our weights and sizes object maps into string literal types:
typeof: This helper takes an object and converts it to a type. For instance typeof weights would return type { bold: string, semibold: string, ...etc}
keyof: This helper function takes a type and returns a list of string literals from that type’s keys. For instance keyof type { bold: string, semibold: string, ...etc} would return "bold" | "semibold" | ...etc which is exactly what we want for both weights and sizes.
---
// ./src/component/Heading.astro
import type { HTMLAttributes } from 'astro/types';

interface Props extends HTMLAttributes<'h1'> {
  as: "h1" | "h2" | "h3" | "h4" | "h5" | "h6";
  weight?: keyof typeof weights;
  size?: keyof typeof sizes;
}

// ... The rest of the file
Now, when we want to add a size or weight, we get a dropdown list in our code editor showing exactly what’s available on the type. If something is selected, outside the list, it will show an error in the code editor helping the developer know what they missed.








While none of this is necessary in the creation of Astro components, the fact that it’s built in and there’s no additional tooling to set up means that using it is very easy to opt into.
I’m by no means a TypeScript expert, but getting this set up for each component takes only a few additional minutes and can save a lot of time for developers down the line (not to mention, it makes onboarding developers to your system much easier).


Crafting Strong DX With Astro Components and TypeScript originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

One thing we can do to help teams code consistently is provide type-checking so that all of the configurable options for a specific component are available while coding. Bryan demonstrates how he does this with TypeScript when working with Astro components.
Crafting Strong DX With Astro Components and TypeScript originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Crafting Strong DX With Astro Components and TypeScript

<p>Interactive CSS animations with elements ricocheting off each other seem more plausible in 2025. While it’s unnecessary to implement Pong in CSS, the increasing flexibility and power of CSS reinforce Lee's suspicion that one day it will be a lifestyle choice whether to achieve any given effect with scripting or CSS.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/worlds-collide-keyframe-collision-detection-using-style-queries/">Worlds Collide: Keyframe Collision Detection Using Style 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>



<p><em>A friend DMs Lee Meyer a <a href="https://codepen.io/ultraschaller/pen/BjJNpG" rel="noopener">CodePen</a> by <a href="https://codepen.io/ultraschaller" rel="noopener">Manuel Schaller</a> containing a pure CSS simulation of one of the <a href="https://en.wikipedia.org/wiki/Pong" rel="noopener">world’s earliest arcade games</a>, Pong, with both paddles participating automatically, in an endless loop. The demo reminds Lee of an arcade machine in <a href="https://tvtropes.org/pmwiki/pmwiki.php/Main/AttractMode" rel="noopener">attract mode</a> awaiting a coin, and the iconic imagery awakens muscle memory from his misspent childhood, causing him to search his pocket in which he finds the token a spooky shopkeeper gave him last year at the CSS tricks stall in the haunted carnival. The token gleams like a power-up in the light of his laptop, which has a slot he never noticed. He feeds the token into the slot, and the CodePen reloads itself. A vertical range input and a life counter appear, allowing him to control the left paddle and play the game in Chrome using a cocktail of modern and experimental CSS features to implement collision detection in CSS animations. He recalls the spooky shopkeeper’s warning that playing with these features has driven some developers to madness, but the shopkeeper’s voice in Lee’s head whispers: “Too late, we are already playing.”</em></p>



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


<h3 class="wp-block-heading" id="css-collision-detection-past-and-present">CSS collision detection: Past and present</h3>


<p>So, maybe the experience of using modern CSS to add collision detection and interactivity to an animation wasn’t as much like a screenplay sponsored by CSS as I depicted in the intro above — but it did feel like magic compared to what <a href="https://www.sitepoint.com/css3-pong-insane-things-to-do-with-css/" rel="noopener">Alex Walker had to go through</a> in 2013 to achieve a similar effect. Hilariously, he describes his implementation as “a glittering city of hacks built on the banks of the ol’ Hack River. On the Planet Hack.“ <a href="https://codepen.io/alexmwalker/pen/DzNPej" rel="noopener">Alex’s version of CSS Pong</a> cleverly combines <a href="https://css-tricks.com/the-checkbox-hack/">checkbox hacks</a>, <a href="https://css-tricks.com/almanac/selectors/g/general-sibling/">sibling selectors</a>, and <a href="https://css-tricks.com/almanac/pseudo-selectors/h/hover/"><code>:hover</code></a>, whereas the CodePen below uses style queries to detect collisions. I feel it’s a nice illustration of how far CSS has come, and a testament to increased power and expressiveness of CSS more than a decade later. It shows how much power we get when combining new CSS features — in this case, that includes <a href="https://css-tricks.com/css-container-queries/">style queries</a>, <a href="https://css-tricks.com/exploring-property-and-its-animating-powers/">animatable custom properties</a>, and <a href="https://css-tricks.com/almanac/properties/a/animation-timeline/">animation timelines</a>. The future CSS features of <a href="https://css-tricks.com/if-css-gets-inline-conditionals/">inline conditionals</a> and <a href="https://css-tricks.com/functions-in-css/">custom functions</a> might be able to simplify this code more.</p>



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


<h3 class="wp-block-heading" id="collision-detection-with-style-queries">Collision detection with style queries</h3>


<p>Interactive CSS animations with elements ricocheting off each other seems more plausible in 2025 and the code is somewhat sensible. While it’s unnecessary to implement Pong in CSS, and the CSS Working Group probably hasn’t been contemplating how to make that particular niche task easier, the increasing flexibility and power of CSS reinforce my suspicion that one day it will be a lifestyle choice whether to achieve any given effect with scripting or CSS.</p>



<p>The demo is a similar number of lines of CSS to Alex’s 2013 implementation, but it didn’t feel much like a hack. It’s a demo of modern CSS features working together in the way I expected after reading the instruction booklet. Sometimes when reading introductory articles about the new features we are getting in CSS, it’s hard to appreciate how game-changing they are till you see several features working together. As often happens when pushing the boundaries of a technology, we are going to bump up against the current limitations of style queries and animations. But it’s all in good fun, and we’ll learn about these CSS features in more detail than if we had not attempted this crazy experiment.</p>



<p>It does seem to work, and my 12-year-old and 7-year-old have both playtested it on my phone and laptop, so it gets the “works on Lee’s devices” seal of quality. Also, since Chrome now supports controlling <a href="https://codepen.io/t_afif/pen/GRbawQm" rel="noopener">animations using range inputs</a>, we can make our game playable on mobile, unlike the 2013 version, which relied on <a href="https://css-tricks.com/almanac/pseudo-selectors/h/hover/"><code>:hover</code></a>. Temani Afif provides a <a href="https://css-tricks.com/a-css-only-star-rating-component-and-more-part-2/#aa-why-scroll-driven-animations">great explanation</a> of how and why <a href="https://css-tricks.com/almanac/properties/v/view-timeline-name/">view progress timelines</a> can be used to style anything based on the value of a range input.</p>


<h2 class="wp-block-heading" id="using-style-queries-to-detect-if-the-paddle-hit-the-ball">Using style queries to detect if the paddle hit the ball</h2>


<p>The ball follows a fixed path, and whether the player’s paddle intersects with the ball when it reaches our side is the only input we have into whether it continues its predetermined bouncy loop or the screen flashes red as the life counter goes down till we see the “Game Over” screen with the option to play again.</p>



<p>This type of interactivity is what game designers call a <a href="https://en.wikipedia.org/wiki/Quick_time_event" rel="noopener">quick time event</a>. It’s still a game for sure, but five months ago, when I was young and naive, I mused in my article on <a href="https://css-tricks.com/slide-through-unlimited-dimensions-with-css-scroll-timelines/">animation timelines</a> that the animation timeline feature could open the door for advanced games and interactive experiences in CSS. I wrote that a video game is just a “hyper-interactive animation.” Indeed, the above experiment shows that the new features in CSS allow us to respond to user input in sophisticated ways, but the demo also clarifies the difference between the kind of interactivity we can expect from the current incarnation of CSS versus scripting. The above experiment is more like if Pong were a game inside the old-school arcade game <a href="https://www.digitalspy.com/videogames/retro-gaming/a593480/dragons-lair-retrospective-how-the-quick-time-event-was-born/" rel="noopener">Dragon’s Lair</a>, which was one giant quick time event. It only works because there are limited possible outcomes, but they are certainly less limited than what we used to be able to achieve in CSS.</p>



<p>Since we know collision detection with the paddle is the only opportunity for the user to have a say in what happens next, let’s focus on that implementation. It will require more mental gymnastics than I would like, since container style queries only allow for <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_size_and_style_queries#container_style_queries" rel="noopener">name-value pairs</a> with the same syntax as <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_conditional_rules/Using_feature_queries" rel="noopener">feature queries</a>, meaning we can’t use “greater than” or “less than” operators when comparing numeric values like we do with <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_size_and_style_queries#container_size_queries" rel="noopener">container size queries</a> which follow the same syntax as <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media" rel="noopener"><code>@media</code> size queries</a>.</p>



<p>The workaround below allows us to create style queries based on the ball position being in or out of the range of the paddle. If the ball hits our side, then by default, the play field will flash red and temporarily unpause the animation that decrements the life counter (more on that later). But if the ball hits our side and is within range of the paddle, we leave the life-decrementing animation paused, and make the field background green while the ball hits the paddle. Since we don’t have “greater than” or “less than” operators in style queries, we (ab)use the <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/min" rel="noopener"><code>min()</code></a> function. If the result equals the first argument then that argument is less than or equal to the second; otherwise it’s greater than the second argument. It’s logical but made me wish for better comparison operators in style queries. Nevertheless, I was impressed that style queries allow the collision detection to be fairly readable, if a little more verbose than I would like.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">body {
  --int-ball-position-x: round(down, var(--ball-position-x));
  --min-ball-position-y-and-top-of-paddle: min(var(--ball-position-y) + var(--ball-height), var(--ping-position));
  --min-ball-position-y-and-bottom-of-paddle: min(var(--ball-position-y), var(--ping-position) + var(--paddle-height));
}

@container style(--int-ball-position-x: var(--ball-left-boundary)) {
  .screen {
    --lives-decrement: running;
      
    .field {
      background: red;
    }
  }
}

@container style(--min-ball-position-y-and-top-of-paddle: var(--ping-position)) and style(--min-ball-position-y-and-bottom-of-paddle: var(--ball-position-y)) and style(--int-ball-position-x: var(--ball-left-boundary)) {
  .screen {
    --lives-decrement: paused;

    .field {
      background: green;
    }
  }
}</code></pre>


<h3 class="wp-block-heading" id="responding-to-collisions">Responding to collisions</h3>


<p>Now that we can style our playing field based on whether the paddle hits the ball, we want to decrement the life counter if our paddle misses the ball, and display “Game Over” when we run out of lives. One way to achieve side effects in CSS is by pausing and unpausing keyframe animations that run forwards. These days, we can style things based on custom properties, which we can set in animations. Using this fact, we can take the power of paused animations to another level.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">
body {
  animation: ball 8s infinite linear, lives 80ms forwards steps(4) var(--lives-decrement);
  --lives-decrement: paused;        
}

.lives::after {
   content: var(--lives);
}

@keyframes lives {
  0% {
    --lives: "3";
  }
  25% {
    --lives: "2";
  }
  75% {
    --lives: "1";
  }
  100% {
    --lives: "0";
  }
}

@container style(--int-ball-position-x: var(--ball-left-boundary)) {
  .screen {
    --lives-decrement: running;
      
    .field {
      background: red;
    }
  }
}

@container style(--min-ball-position-y-and-top-of-paddle: var(--ping-position)) and style(--min-ball-position-y-and-bottom-of-paddle: var(--ball-position-y)) and style(--int-ball-position-x: 8) {
  .screen {
    --lives-decrement: paused;
    
    .field {
      background: green;
    }
  }
}

@container style(--lives: '0') {
  .field {
     display: none;
  }
  
  .game-over {
     display: flex;
  }
}</code></pre>



<p>So when the ball hits the wall and isn’t in range of the paddle, the lives-decrementing animation is unpaused long enough to let it complete one step. Once it reaches zero we hide the play field and display the “Game Over” screen. What’s fascinating about this part of the experiment is that it shows that, using style queries, all properties become indirectly possible to control via animations, even when working with non-animatable properties. And this applies to properties that control whether other animations play. This <a href="https://dev.to/janeori/expert-css-the-cpu-hack-4ddj" rel="noopener">article</a> touches on why play state deliberately isn’t animatable and could be dangerous to animate, but we know what we are doing, right?</p>



<p>Full disclosure: The play state approach did lead to hidden complexity in the choice of duration of the animations. I knew that if I chose too long a duration for the life-decrementing counter, it might not have time to proceed to the next step while the ball was hitting the wall, but if I chose too short a duration, missing the ball once might cause the player to lose more than one life.</p>



<p>I made educated guesses of suitable durations for the ball bouncing and life decrementing, and I expected that when working with fixed-duration predictable animations, the life counter would either always work or always fail. I didn’t expect that my first attempt at the implementation intermittently failed to decrement the life counter at the same point in the animation loop. Setting the durations of both these related animations to multiples of eight seems to fix the problem, but why would predetermined animations exhibit unpredictable behavior?</p>


<h3 class="wp-block-heading" id="forefeit-the-game-before-somebody-else-takes-you-out-of-the-frame">Forefeit the game before somebody else takes you out of the frame</h3>


<p>I have theories as to why the unpredictability of the collision detection seemed to be fixed by setting the ball animation to eight seconds and the lives animation to 80 milliseconds. Again, pushing CSS to its limits forces us to think deeper about how it’s working.</p>



<ol class="wp-block-list">
<li>CSS appears to suffer from <a href="https://stackoverflow.com/questions/8715088/do-css-animations-work-on-strict-time-basis" rel="noopener">timer drift</a>, meaning if you set a keyframes animation to last for one second, it will <a href="https://jsfiddle.net/DPWn7/" rel="noopener">sometimes take slightly under or over one second</a>. When there is a different rate of change between the ball-bouncing and life-losing, it would make sense that the potential discrepancy between the two would be pronounced and lead to unpredictable collision detection. When the rate of change in both animations is the same, they would suffer about equally from timer drift, meaning the frames still synchronize predictably. Or at least I’m hoping the chance they don’t becomes negligible.</li>



<li>Alex’s 2013 version of Pong uses <code><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/transform-function/translate3d" rel="noopener">translate3d()</a></code> to move the ball even though it only moves in 2D. Alex recommends this whenever possible “for efficient animation rendering, offloading processing to the GPU for smoother visual effects.” Doing this may have been an alternative fix if it leads to more precise animation timing. There are <a href="https://css-tricks.com/myth-busting-css-animations-vs-javascript/">tradeoffs</a> so I wasn’t willing to go down that rabbit hole of trying to tune the animation performance in this article — but it could be an interesting focus for future research into CSS collision detection.</li>



<li>Maybe style queries take a varying amount of time to kick in, leading to some form of a <a href="https://en.wikipedia.org/wiki/Race_condition" rel="noopener">race condition</a>. It is possible that making the ball-bouncing animation slower made this problem less likely.</li>



<li>Maybe the bug remains lurking in the shadows somewhere. What did I expect from a hack I achieved using a magic token from a spooky shopkeeper? Haven’t I seen any eighties movie ever?</li>
</ol>


<h3 class="wp-block-heading" id="outro">Outro</h3>


<p><em>You finish reading the article, and feel sure that the author’s rationale for his supposed fix for the bug is hogwash. Clearly, Lee has been driven insane by the allure of overpowering new CSS features, whereas you respect the power of CSS, but you also respect its limitations. You sit down to spend a few minutes with the collision detection CodePen to prove it is still broken, but then find other flaws in the collision detection, and you commence work on a fork that will be superior. Hey, speaking of timer drift, how is it suddenly 1 a.m.? Only a crazy person would stay up that late playing with CSS when they have to work the next day. “Madness,” repeats the spooky shopkeeper inside your head, and his laughter echoes somewhere in the night.</em></p>


<h2 class="wp-block-heading" id="roll-the-credits">Roll the credits</h2>


<p>This looping <a href="https://codepen.io/ultraschaller/pen/BjJNpG" rel="noopener">Pong CSS animation</a> by <a href="https://codepen.io/ultraschaller" rel="noopener">Manuel Schaller</a> gave me an amazing basis for adding the collision detection. His twitching paddle animations help give the illusion of playing against a computer opponent, so forking his CodePen let me focus on implementing the collision detection rather than reinventing Pong.</p>



<p>This author is grateful to the junior testing team, comprised of his seven-year-old and twelve-year-old, who declared the CSS Pong implementation “pretty cool.” They also suggested the green and red flashes to signal collisions and misses.</p>



<p>The intro and outro for this article were sponsored by the spooky shopkeeper who sells dangerous CSS tricks. He also sells frozen yoghurt, which he calls <em>froghurt</em>.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/worlds-collide-keyframe-collision-detection-using-style-queries/">Worlds Collide: Keyframe Collision Detection Using Style 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>


A friend DMs Lee Meyer a CodePen by Manuel Schaller containing a pure CSS simulation of one of the world’s earliest arcade games, Pong, with both paddles participating automatically, in an endless loop. The demo reminds Lee of an arcade machine in attract mode awaiting a coin, and the iconic imagery awakens muscle memory from his misspent childhood, causing him to search his pocket in which he finds the token a spooky shopkeeper gave him last year at the CSS tricks stall in the haunted carnival. The token gleams like a power-up in the light of his laptop, which has a slot he never noticed. He feeds the token into the slot, and the CodePen reloads itself. A vertical range input and a life counter appear, allowing him to control the left paddle and play the game in Chrome using a cocktail of modern and experimental CSS features to implement collision detection in CSS animations. He recalls the spooky shopkeeper’s warning that playing with these features has driven some developers to madness, but the shopkeeper’s voice in Lee’s head whispers: “Too late, we are already playing.”



CSS collision detection: Past and present
So, maybe the experience of using modern CSS to add collision detection and interactivity to an animation wasn’t as much like a screenplay sponsored by CSS as I depicted in the intro above — but it did feel like magic compared to what Alex Walker had to go through in 2013 to achieve a similar effect. Hilariously, he describes his implementation as “a glittering city of hacks built on the banks of the ol’ Hack River. On the Planet Hack.“ Alex’s version of CSS Pong cleverly combines checkbox hacks, sibling selectors, and :hover, whereas the CodePen below uses style queries to detect collisions. I feel it’s a nice illustration of how far CSS has come, and a testament to increased power and expressiveness of CSS more than a decade later. It shows how much power we get when combining new CSS features — in this case, that includes style queries, animatable custom properties, and animation timelines. The future CSS features of inline conditionals and custom functions might be able to simplify this code more.
CodePen Embed Fallback
Collision detection with style queries
Interactive CSS animations with elements ricocheting off each other seems more plausible in 2025 and the code is somewhat sensible. While it’s unnecessary to implement Pong in CSS, and the CSS Working Group probably hasn’t been contemplating how to make that particular niche task easier, the increasing flexibility and power of CSS reinforce my suspicion that one day it will be a lifestyle choice whether to achieve any given effect with scripting or CSS.
The demo is a similar number of lines of CSS to Alex’s 2013 implementation, but it didn’t feel much like a hack. It’s a demo of modern CSS features working together in the way I expected after reading the instruction booklet. Sometimes when reading introductory articles about the new features we are getting in CSS, it’s hard to appreciate how game-changing they are till you see several features working together. As often happens when pushing the boundaries of a technology, we are going to bump up against the current limitations of style queries and animations. But it’s all in good fun, and we’ll learn about these CSS features in more detail than if we had not attempted this crazy experiment.
It does seem to work, and my 12-year-old and 7-year-old have both playtested it on my phone and laptop, so it gets the “works on Lee’s devices” seal of quality. Also, since Chrome now supports controlling animations using range inputs, we can make our game playable on mobile, unlike the 2013 version, which relied on :hover. Temani Afif provides a great explanation of how and why view progress timelines can be used to style anything based on the value of a range input.
Using style queries to detect if the paddle hit the ball
The ball follows a fixed path, and whether the player’s paddle intersects with the ball when it reaches our side is the only input we have into whether it continues its predetermined bouncy loop or the screen flashes red as the life counter goes down till we see the “Game Over” screen with the option to play again.
This type of interactivity is what game designers call a quick time event. It’s still a game for sure, but five months ago, when I was young and naive, I mused in my article on animation timelines that the animation timeline feature could open the door for advanced games and interactive experiences in CSS. I wrote that a video game is just a “hyper-interactive animation.” Indeed, the above experiment shows that the new features in CSS allow us to respond to user input in sophisticated ways, but the demo also clarifies the difference between the kind of interactivity we can expect from the current incarnation of CSS versus scripting. The above experiment is more like if Pong were a game inside the old-school arcade game Dragon’s Lair, which was one giant quick time event. It only works because there are limited possible outcomes, but they are certainly less limited than what we used to be able to achieve in CSS.
Since we know collision detection with the paddle is the only opportunity for the user to have a say in what happens next, let’s focus on that implementation. It will require more mental gymnastics than I would like, since container style queries only allow for name-value pairs with the same syntax as feature queries, meaning we can’t use “greater than” or “less than” operators when comparing numeric values like we do with container size queries which follow the same syntax as @media size queries.
The workaround below allows us to create style queries based on the ball position being in or out of the range of the paddle. If the ball hits our side, then by default, the play field will flash red and temporarily unpause the animation that decrements the life counter (more on that later). But if the ball hits our side and is within range of the paddle, we leave the life-decrementing animation paused, and make the field background green while the ball hits the paddle. Since we don’t have “greater than” or “less than” operators in style queries, we (ab)use the min() function. If the result equals the first argument then that argument is less than or equal to the second; otherwise it’s greater than the second argument. It’s logical but made me wish for better comparison operators in style queries. Nevertheless, I was impressed that style queries allow the collision detection to be fairly readable, if a little more verbose than I would like.
body {
  --int-ball-position-x: round(down, var(--ball-position-x));
  --min-ball-position-y-and-top-of-paddle: min(var(--ball-position-y) + var(--ball-height), var(--ping-position));
  --min-ball-position-y-and-bottom-of-paddle: min(var(--ball-position-y), var(--ping-position) + var(--paddle-height));
}

@container style(--int-ball-position-x: var(--ball-left-boundary)) {
  .screen {
    --lives-decrement: running;
      
    .field {
      background: red;
    }
  }
}

@container style(--min-ball-position-y-and-top-of-paddle: var(--ping-position)) and style(--min-ball-position-y-and-bottom-of-paddle: var(--ball-position-y)) and style(--int-ball-position-x: var(--ball-left-boundary)) {
  .screen {
    --lives-decrement: paused;

    .field {
      background: green;
    }
  }
}
Responding to collisions
Now that we can style our playing field based on whether the paddle hits the ball, we want to decrement the life counter if our paddle misses the ball, and display “Game Over” when we run out of lives. One way to achieve side effects in CSS is by pausing and unpausing keyframe animations that run forwards. These days, we can style things based on custom properties, which we can set in animations. Using this fact, we can take the power of paused animations to another level.

body {
  animation: ball 8s infinite linear, lives 80ms forwards steps(4) var(--lives-decrement);
  --lives-decrement: paused;        
}

.lives::after {
   content: var(--lives);
}

@keyframes lives {
  0% {
    --lives: "3";
  }
  25% {
    --lives: "2";
  }
  75% {
    --lives: "1";
  }
  100% {
    --lives: "0";
  }
}

@container style(--int-ball-position-x: var(--ball-left-boundary)) {
  .screen {
    --lives-decrement: running;
      
    .field {
      background: red;
    }
  }
}

@container style(--min-ball-position-y-and-top-of-paddle: var(--ping-position)) and style(--min-ball-position-y-and-bottom-of-paddle: var(--ball-position-y)) and style(--int-ball-position-x: 8) {
  .screen {
    --lives-decrement: paused;
    
    .field {
      background: green;
    }
  }
}

@container style(--lives: '0') {
  .field {
     display: none;
  }
  
  .game-over {
     display: flex;
  }
}
So when the ball hits the wall and isn’t in range of the paddle, the lives-decrementing animation is unpaused long enough to let it complete one step. Once it reaches zero we hide the play field and display the “Game Over” screen. What’s fascinating about this part of the experiment is that it shows that, using style queries, all properties become indirectly possible to control via animations, even when working with non-animatable properties. And this applies to properties that control whether other animations play. This article touches on why play state deliberately isn’t animatable and could be dangerous to animate, but we know what we are doing, right?
Full disclosure: The play state approach did lead to hidden complexity in the choice of duration of the animations. I knew that if I chose too long a duration for the life-decrementing counter, it might not have time to proceed to the next step while the ball was hitting the wall, but if I chose too short a duration, missing the ball once might cause the player to lose more than one life.
I made educated guesses of suitable durations for the ball bouncing and life decrementing, and I expected that when working with fixed-duration predictable animations, the life counter would either always work or always fail. I didn’t expect that my first attempt at the implementation intermittently failed to decrement the life counter at the same point in the animation loop. Setting the durations of both these related animations to multiples of eight seems to fix the problem, but why would predetermined animations exhibit unpredictable behavior?
Forefeit the game before somebody else takes you out of the frame
I have theories as to why the unpredictability of the collision detection seemed to be fixed by setting the ball animation to eight seconds and the lives animation to 80 milliseconds. Again, pushing CSS to its limits forces us to think deeper about how it’s working.
CSS appears to suffer from timer drift, meaning if you set a keyframes animation to last for one second, it will sometimes take slightly under or over one second. When there is a different rate of change between the ball-bouncing and life-losing, it would make sense that the potential discrepancy between the two would be pronounced and lead to unpredictable collision detection. When the rate of change in both animations is the same, they would suffer about equally from timer drift, meaning the frames still synchronize predictably. Or at least I’m hoping the chance they don’t becomes negligible.
Alex’s 2013 version of Pong uses translate3d() to move the ball even though it only moves in 2D. Alex recommends this whenever possible “for efficient animation rendering, offloading processing to the GPU for smoother visual effects.” Doing this may have been an alternative fix if it leads to more precise animation timing. There are tradeoffs so I wasn’t willing to go down that rabbit hole of trying to tune the animation performance in this article — but it could be an interesting focus for future research into CSS collision detection.
Maybe style queries take a varying amount of time to kick in, leading to some form of a race condition. It is possible that making the ball-bouncing animation slower made this problem less likely.
Maybe the bug remains lurking in the shadows somewhere. What did I expect from a hack I achieved using a magic token from a spooky shopkeeper? Haven’t I seen any eighties movie ever?
Outro
You finish reading the article, and feel sure that the author’s rationale for his supposed fix for the bug is hogwash. Clearly, Lee has been driven insane by the allure of overpowering new CSS features, whereas you respect the power of CSS, but you also respect its limitations. You sit down to spend a few minutes with the collision detection CodePen to prove it is still broken, but then find other flaws in the collision detection, and you commence work on a fork that will be superior. Hey, speaking of timer drift, how is it suddenly 1 a.m.? Only a crazy person would stay up that late playing with CSS when they have to work the next day. “Madness,” repeats the spooky shopkeeper inside your head, and his laughter echoes somewhere in the night.
Roll the credits
This looping Pong CSS animation by Manuel Schaller gave me an amazing basis for adding the collision detection. His twitching paddle animations help give the illusion of playing against a computer opponent, so forking his CodePen let me focus on implementing the collision detection rather than reinventing Pong.
This author is grateful to the junior testing team, comprised of his seven-year-old and twelve-year-old, who declared the CSS Pong implementation “pretty cool.” They also suggested the green and red flashes to signal collisions and misses.
The intro and outro for this article were sponsored by the spooky shopkeeper who sells dangerous CSS tricks. He also sells frozen yoghurt, which he calls froghurt.
Worlds Collide: Keyframe Collision Detection Using Style Queries originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Interactive CSS animations with elements ricocheting off each other seem more plausible in 2025. While it’s unnecessary to implement Pong in CSS, the increasing flexibility and power of CSS reinforce Lee's suspicion that one day it will be a lifestyle choice whether to achieve any given effect with scripting or CSS.
Worlds Collide: Keyframe Collision Detection Using Style Queries originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Worlds Collide: Keyframe Collision Detection Using Style Queries

<p>With visual regression testing, we can update a page, take screenshots before and after the fact, and compare the results for unintended changes. In this article, learn how to set up visual regression testing using Playwright.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/automated-visual-regression-testing-with-playwright/">Automated Visual Regression Testing With Playwright</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>


Comparing visual artifacts can be a powerful, if fickle, approach to automated testing. Playwright makes this seem simple for websites, but the details might take a little finessing.
Recent downtime prompted me to scratch an itch that had been plaguing me for a while: The style sheet of a website I maintain has grown just a little unwieldy as we’ve been adding code while exploring new features. Now that we have a better idea of the requirements, it’s time for internal CSS refactoring to pay down some of our technical debt, taking advantage of modern CSS features (like using CSS nesting for more obvious structure). More importantly, a cleaner foundation should make it easier to introduce that dark mode feature we’re sorely lacking so we can finally respect users’ preferred color scheme.
However, being of the apprehensive persuasion, I was reluctant to make large changes for fear of unwittingly introducing bugs. I needed something to guard against visual regressions while refactoring — except that means snapshot testing, which is notoriously slow and brittle.
In this context, snapshot testing means taking screenshots to establish a reliable baseline against which we can compare future results. As we’ll see, those artifacts are influenced by a multitude of factors that might not always be fully controllable (e.g. timing, variable hardware resources, or randomized content). We also have to maintain state between test runs, i.e. save those screenshots, which complicates the setup and means our test code alone doesn’t fully describe expectations.
Having procrastinated without a more agreeable solution revealing itself, I finally set out to create what I assumed would be a quick spike. After all, this wouldn’t be part of the regular test suite; just a one-off utility for this particular refactoring task.




Fortunately, I had vague recollections of past research and quickly rediscovered Playwright’s built-in visual comparison feature. Because I try to select dependencies carefully, I was glad to see that Playwright seems not to rely on many external packages.
Setup
The recommended setup with npm init playwright@latest does a decent job, but my minimalist taste had me set everything up from scratch instead. This do-it-yourself approach also helped me understand how the different pieces fit together.
Given that I expect snapshot testing to only be used on rare occasions, I wanted to isolate everything in a dedicated subdirectory, called test/visual; that will be our working directory from here on out. We’ll start with package.json to declare our dependencies, adding a few helper scripts (spoiler!) while we’re at it:
{
  "scripts": {
    "test": "playwright test",
    "report": "playwright show-report",
    "update": "playwright test --update-snapshots",
    "reset": "rm -r ./playwright-report ./test-results ./viz.test.js-snapshots || true"
  },
  "devDependencies": {
    "@playwright/test": "^1.49.1"
  }
}
If you don’t want node_modules hidden in some subdirectory but also don’t want to burden the root project with this rarely-used dependency, you might resort to manually invoking npm install --no-save @playwright/test in the root directory when needed.
With that in place, npm install downloads Playwright. Afterwards, npx playwright install downloads a range of headless browsers. (We’ll use npm here, but you might prefer a different package manager and task runner.)
We define our test environment via playwright.config.js with about a dozen basic Playwright settings:
import { defineConfig, devices } from "@playwright/test";

let BROWSERS = ["Desktop Firefox", "Desktop Chrome", "Desktop Safari"];
let BASE_URL = "http://localhost:8000";
let SERVER = "cd ../../dist && python3 -m http.server";

let IS_CI = !!process.env.CI;

export default defineConfig({
  testDir: "./",
  fullyParallel: true,
  forbidOnly: IS_CI,
  retries: 2,
  workers: IS_CI ? 1 : undefined,
  reporter: "html",
  webServer: {
    command: SERVER,
    url: BASE_URL,
    reuseExistingServer: !IS_CI
  },
  use: {
    baseURL: BASE_URL,
    trace: "on-first-retry"
  },
  projects: BROWSERS.map(ua => ({
    name: ua.toLowerCase().replaceAll(" ", "-"),
    use: { ...devices[ua] }
  }))
});
Here we expect our static website to already reside within the root directory’s dist folder and to be served at localhost:8000 (see SERVER; I prefer Python there because it’s widely available). I’ve included multiple browsers for illustration purposes. Still, we might reduce that number to speed things up (thus our simple BROWSERS list, which we then map to Playwright’s more elaborate projects data structure). Similarly, continuous integration is YAGNI for my particular scenario, so that whole IS_CI dance could be discarded.
Capture and compare
Let’s turn to the actual tests, starting with a minimal sample.test.js file:
import { test, expect } from "@playwright/test";

test("home page", async ({ page }) => {
  await page.goto("/");
  await expect(page).toHaveScreenshot();
});
npm test executes this little test suite (based on file-name conventions). The initial run always fails because it first needs to create baseline snapshots against which subsequent runs compare their results. Invoking npm test once more should report a passing test.
Changing our site, e.g. by recklessly messing with build artifacts in dist, should make the test fail again. Such failures will offer various options to compare expected and actual visuals:




We can also inspect those baseline snapshots directly: Playwright creates a folder for screenshots named after the test file (sample.test.js-snapshots in this case), with file names derived from the respective test’s title (e.g. home-page-desktop-firefox.png).
Generating tests
Getting back to our original motivation, what we want is a test for every page. Instead of arduously writing and maintaining repetitive tests, we’ll create a simple web crawler for our website and have tests generated automatically; one for each URL we’ve identified.
Playwright’s global setup enables us to perform preparatory work before test discovery begins: Determine those URLs and write them to a file. Afterward, we can dynamically generate our tests at runtime.
While there are other ways to pass data between the setup and test-discovery phases, having a file on disk makes it easy to modify the list of URLs before test runs (e.g. temporarily ignoring irrelevant pages).
Site map
The first step is to extend playwright.config.js by inserting globalSetup and exporting two of our configuration values:
export let BROWSERS = ["Desktop Firefox", "Desktop Chrome", "Desktop Safari"];
export let BASE_URL = "http://localhost:8000";

// etc.

export default defineConfig({
  // etc.
  globalSetup: require.resolve("./setup.js")
});
Although we’re using ES modules here, we can still rely on CommonJS-specific APIs like require.resolve and __dirname. It appears there’s some Babel transpilation happening in the background, so what’s actually being executed is probably CommonJS? Such nuances sometimes confuse me because it isn’t always obvious what’s being executed where.
We can now reuse those exported values within a newly created setup.js, which spins up a headless browser to crawl our site (just because that’s easier here than using a separate HTML parser):
import { BASE_URL, BROWSERS } from "./playwright.config.js";
import { createSiteMap, readSiteMap } from "./sitemap.js";
import playwright from "@playwright/test";

export default async function globalSetup(config) {
  // only create site map if it doesn't already exist
  try {
    readSiteMap();
    return;
  } catch(err) {}

  // launch browser and initiate crawler
  let browser = playwright.devices[BROWSERS[0]].defaultBrowserType;
  browser = await playwright[browser].launch();
  let page = await browser.newPage();
  await createSiteMap(BASE_URL, page);
  await browser.close();
}
This is fairly boring glue code; the actual crawling is happening within sitemap.js:
createSiteMap determines URLs and writes them to disk.
readSiteMap merely reads any previously created site map from disk. This will be our foundation for dynamically generating tests. (We’ll see later why this needs to be synchronous.)
Fortunately, the website in question provides a comprehensive index of all pages, so my crawler only needs to collect unique local URLs from that index page:
function extractLocalLinks(baseURL) {
  let urls = new Set();
  let offset = baseURL.length;
  for(let { href } of document.links) {
    if(href.startsWith(baseURL)) {
      let path = href.slice(offset);
      urls.add(path);
    }
  }
  return Array.from(urls);
}
Wrapping that in a more boring glue code gives us our sitemap.js:
import { readFileSync, writeFileSync } from "node:fs";
import { join } from "node:path";

let ENTRY_POINT = "/topics";
let SITEMAP = join(__dirname, "./sitemap.json");

export async function createSiteMap(baseURL, page) {
  await page.goto(baseURL + ENTRY_POINT);
  let urls = await page.evaluate(extractLocalLinks, baseURL);
  let data = JSON.stringify(urls, null, 4);
  writeFileSync(SITEMAP, data, { encoding: "utf-8" });
}

export function readSiteMap() {
  try {
    var data = readFileSync(SITEMAP, { encoding: "utf-8" });
  } catch(err) {
    if(err.code === "ENOENT") {
      throw new Error("missing site map");
    }
    throw err;
  }
  return JSON.parse(data);
}

function extractLocalLinks(baseURL) {
  // etc.
}
The interesting bit here is that extractLocalLinks is evaluated within the browser context — thus we can rely on DOM APIs, notably document.links — while the rest is executed within the Playwright environment (i.e. Node).
Tests
Now that we have our list of URLs, we basically just need a test file with a simple loop to dynamically generate corresponding tests:
for(let url of readSiteMap()) {
  test(`page at ${url}`, async ({ page }) => {
    await page.goto(url);
    await expect(page).toHaveScreenshot();
  });
}
This is why readSiteMap had to be synchronous above: Playwright doesn’t currently support top-level await within test files.
In practice, we’ll want better error reporting for when the site map doesn’t exist yet. Let’s call our actual test file viz.test.js:
import { readSiteMap } from "./sitemap.js";
import { test, expect } from "@playwright/test";

let sitemap = [];
try {
  sitemap = readSiteMap();
} catch(err) {
  test("site map", ({ page }) => {
    throw new Error("missing site map");
  });
}

for(let url of sitemap) {
  test(`page at ${url}`, async ({ page }) => {
    await page.goto(url);
    await expect(page).toHaveScreenshot();
  });
}
Getting here was a bit of a journey, but we’re pretty much done… unless we have to deal with reality, which typically takes a bit more tweaking.
Exceptions
Because visual testing is inherently flaky, we sometimes need to compensate via special casing. Playwright lets us inject custom CSS, which is often the easiest and most effective approach. Tweaking viz.test.js…
// etc.
import { join } from "node:path";

let OPTIONS = {
  stylePath: join(__dirname, "./viz.tweaks.css")
};

// etc.
  await expect(page).toHaveScreenshot(OPTIONS);
// etc.
… allows us to define exceptions in viz.tweaks.css:
/* suppress state */
main a:visited {
  color: var(--color-link);
}

/* suppress randomness */
iframe[src$="/articles/signals-reactivity/demo.html"] {
  visibility: hidden;
}

/* suppress flakiness */
body:has(h1 a[href="/wip/unicode-symbols/"]) {
  main tbody > tr:last-child > td:first-child {
    font-size: 0;
    visibility: hidden;
  }
}
:has() strikes again!
Page vs. viewport
At this point, everything seemed hunky-dory to me, until I realized that my tests didn’t actually fail after I had changed some styling. That’s not good! What I hadn’t taken into account is that .toHaveScreenshot only captures the viewport rather than the entire page. We can rectify that by further extending playwright.config.js.
export let WIDTH = 800;
export let HEIGHT = WIDTH;

// etc.

  projects: BROWSERS.map(ua => ({
    name: ua.toLowerCase().replaceAll(" ", "-"),
    use: {
      ...devices[ua],
      viewport: {
        width: WIDTH,
        height: HEIGHT
      }
    }
  }))
…and then by adjusting viz.test.js‘s test-generating loop:
import { WIDTH, HEIGHT } from "./playwright.config.js";

// etc.

for(let url of sitemap) {
  test(`page at ${url}`, async ({ page }) => {
    checkSnapshot(url, page);
  });
}

async function checkSnapshot(url, page) {
  // determine page height with default viewport
  await page.setViewportSize({
    width: WIDTH,
    height: HEIGHT
  });
  await page.goto(url);
  await page.waitForLoadState("networkidle");
  let height = await page.evaluate(getFullHeight);

  // resize viewport for before snapshotting
  await page.setViewportSize({
    width: WIDTH,
    height: Math.ceil(height)
  });
  await page.waitForLoadState("networkidle");
  await expect(page).toHaveScreenshot(OPTIONS);
}

function getFullHeight() {
  return document.documentElement.getBoundingClientRect().height;
}
Note that we’ve also introduced a waiting condition, holding until there’s no network traffic for a while in a crude attempt to account for stuff like lazy-loading images.
Be aware that capturing the entire page is more resource-intensive and doesn’t always work reliably: You might have to deal with layout shifts or run into timeouts for long or asset-heavy pages. In other words: This risks exacerbating flakiness.
Conclusion
So much for that quick spike. While it took more effort than expected (I believe that’s called “software development”), this might actually solve my original problem now (not a common feature of software these days). Of course, shaving this yak still leaves me itchy, as I have yet to do the actual work of scratching CSS without breaking anything. Then comes the real challenge: Retrofitting dark mode to an existing website. I just might need more downtime.
Automated Visual Regression Testing With Playwright originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

With visual regression testing, we can update a page, take screenshots before and after the fact, and compare the results for unintended changes. In this article, learn how to set up visual regression testing using Playwright.
Automated Visual Regression Testing With Playwright originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Automated Visual Regression Testing With Playwright

<p>Having been tasked with creating a UI component for navigating the content of an online course, Daniel found himself neck-deep in a pool of new CSS features that he wound up using on the project.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/case-study-combining-cutting-edge-css-features-into-a-course-navigation-component/">Case Study: Combining Cutting-Edge CSS Features Into a “Course Navigation” Component</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 came across this awesome article navigator by Jhey Tompkins:
CodePen Embed Fallback
It solved a UX problem I was facing on a project, so I’ve adapted it to the needs of an online course — a “course navigator” if you will — and built upon it. And today I’m going to pick it apart and show you how it all works:




CodePen Embed Fallback
You can see I’m imagining this as some sort of navigation that you might find in an online learning management system that powers an online course. To summarize what this component does, it:
links to all course lessons,
smoothly scrolls to anchored lesson headings,
indicates how much of the current lesson has been read,
toggles between light and dark modes, and
sits fixed at the bottom and collapses on scroll.
Also, while not a feature, we won’t be using JavaScript. You might think that’s impossible, but the spate of CSS features that have recently shipped make all of this possible with vanilla CSS, albeit using bleeding-edge techniques that are only fully supported by Chrome at the time I’m writing this. So, crack open the latest version and let’s do this together!
The HTML
We’re looking at a disclosure widget (the <details> element) pinned to the bottom of the page with fixed positioning. Behind it? A course lesson (or something of that effect) wrapped in an <article> with ids on the headings for same-page anchoring. Clicking on the disclosure’s <summary> toggles the course navigation, which is wrapped in a ::details-content pseudo-element. This navigation links to other lessons but also scrolls to the aforementioned headings of the current lesson.
The <summary> contains a label (since it functions as a toggle-disclosure button), the name of the current lesson, the distance scrolled, and a dark mode toggle.
With me so far?
<details>
  
  
  <summary>
    <span></span>
    <span></span>
    <label></label>
  </summary>
  
  
    
  
    
</details>

<article>
  <h1 id="sectionA">Section A</h1>
  <p>...</p>
  <h2 id="sectionB">Section B</h2>
  <p>...</p>
  <h2 id="sectionC">Section C</h2>
  <p>...</p>
</article>
Getting into position
First, we’ll place the disclosure with fixed positioning so that it’s pinned to the bottom of the page:
details {
  position: fixed;
  inset: 24px; /* Use as margin */
  place-self: end center; /* y x */
}
Setting up CSS-only dark mode (the new way)
There are certain scenarios where dark mode is better for accessibility, especially for the legibility of long-form content, so let’s set that up.
First, the HTML. We have an ugly checkbox input that’s hidden thanks to its hidden attribute, followed by an <i> which’ll be a better-looking faux checkbox once we’ve sprinkled on some Font Awesome, followed by a <span> for the checkbox’s text label. All of this is then wrapped in an actual <label>, which is wrapped by the <summary>. We wrap the label’s content in a <span> so that flexbox gaps get applied between everything.
Functionally, even though the checkbox is hidden, it toggles whenever its label is clicked. And on that note, it might be a good idea to place an explicit aria-label on this label, just to be 100% sure that screen readers announce a label, since implicit labels don’t always get picked up.
<details>

  <summary>
    
    
        
    <label aria-label="Dark mode">
      <input type="checkbox" hidden>
      <i></i>
      <span>Dark mode</span>
    </label>
        
  </summary>
    
  
  
</details>
Next we need to put the right icons in there, subject to a little conditional logic. Rather than use Font Awesome’s HTML classes and have to mess around with CSS overwrites, we’ll use Font Awesome’s CSS properties with our rule logic, as follows:
If the <i> element is followed by (notice the next-sibling combinator) a checked checkbox, we’ll display a checked checkbox icon in it. If it’s followed by an unchecked checkbox, we’ll display an unchecked checkbox icon in it. It’s still the same rule logic even if you don’t use Font Awesome.
/* Copied from Font Awesome’s CSS */
i::before {
  font-style: normal;
  font-family: "Font Awesome 6 Free";
  display: inline-block;
  width: 1.25em; /* Prevents content shift when swapping to differently sized icons by making them all have the same width (this is equivalent to Font Awesome’s .fa-fw class) */
}

/* If followed by a checked checkbox... */
input[type=checkbox]:checked + i::before {
  content: "\f058";
  font-weight: 900;
}

/* If followed by an unchecked checkbox... */
input[type=checkbox]:not(:checked) + i::before {
  content: "\f111";
  font-weight: 400;
}
We need to implement the modes at the root level (again, using a little conditional logic). If the root :has the checked checkbox, apply color-scheme: dark. If the root does :not(:has) the unchecked checkbox, then we apply color-scheme: light.
/* If the root has a checked checkbox... */
:root:has(input[type=checkbox]:checked) {
  color-scheme: dark;
}

/* If the root does not have a checked checkbox... */
:root:not(:has(input[type=checkbox]:checked)) {
  color-scheme: light;
}
If you toggle the checkbox, your web browser’s UI will already toggle between light and dark color schemes. Now let’s make sure that our demo does the same thing using the light-dark() CSS function, which takes two values — the light mode color and then the dark mode color. You can utilize this function instead of any color data type (later on we’ll even use it within a conic gradient).




In the demo I’m using the same HSL color throughout but with different lightness values, then flipping the lightness values based on the mode:
color: light-dark(hsl(var(--hs) 90%), hsl(var(--hs) 10%));
background: light-dark(hsl(var(--hs) 10%), hsl(var(--hs) 90%));
I don’t think the light-dark() function is any better than swapping out CSS variables, but I don’t believe it’s any worse either. Totally up to you as far as which approach you choose.
Displaying scroll progress
Now let’s display the amount read as defined by the scroll progress, first, as what I like to call a “progress pie” and then, second, as a plain-text percentage. These’ll go in the middle part of the <summary>:
<details>

  <summary>
    
    
      
    <span>
      <span id="progress-pie"></span>
      <span>1. LessonA</span>
      <span id="progress-percentage"></span>
    </span>
        
    

  </summary>
    
  
    
</details>
What we need is to display the percentage and allow it to “count” as the scroll position changes. Normally, this is squarely in JavaScript territory. But now that we can define our own custom properties, we can establish a variable called --percentage that is formatted as an integer that defaults to a value of 0. This provides CSS with the context it needs to read and interpolate the value between 0 and 100, which is the maximum value we want to support.
So, first, we define the variable as a custom property:
@property --percentage {
  syntax: "<integer>";
  inherits: true;
  initial-value: 0;
}
Then we define the animation in keyframes so that the value of --percentage is updated from 0 to 100:
@keyframes updatePercentage {
  to {
    --percentage: 100;
  }
}
And, finally, we apply the animation on the root element:
:root {
  animation: updatePercentage;
  animation-timeline: scroll();
  counter-reset: percentage var(--percentage);
}
Notice what we’re doing here: this is a scroll-driven animation! By setting the animation-timeline to scroll(), we’re no longer running the animation based on the document’s timeline but instead based on the user’s scroll position. You can dig deeper into scroll timelines in the CSS-Tricks Almanac.




Since we’re dealing with an integer, we can target the ::before pseudo-element and place the percentage value inside of it using the content property and a little counter() hacking (followed by the percentage symbol):
#progress-percentage::before {
  content: counter(percentage) "%";
  min-width: 40px; display: inline-block; /* Prevents content shift */
}
The progress pie is just as straightforward. It’s a conic gradient made up of two colors that are positioned using 0% and the scroll percentage! This means that you’ll need that --percentage variable as an actual percentage, but you can convert it into such by multiplying it by 1% (calc(var(--percentage) * 1%))!
#progress-pie {
  aspect-ratio: 1;
  background: conic-gradient(hsl(var(--hs) 50%) calc(var(--percentage) * 1%), light-dark(hsl(var(--hs) 90%), hsl(var(--hs) 10%)) 0%);
  border-radius: 50%; /* Make it a circle */
  width: 17px; /* Same dimensions as the icons */
}
Creating a (good) course navigation
Now for the table contents containing the nested lists of lesson sections within them, starting with some resets. While there are more resets in the demo and more lines of code overall, two specific resets are vital to the UX of this component.
First, here’s an example of how the nested lists are marked up:
<details>

  <summary>
    
  </summary>
  
  <ol>
    <li class="active">
      <a>LessonA</a>
      <ol>
        <li><a href="#sectionA">SectionA</a></li>
        <li><a href="#sectionB">SectionB</a></li>
        <li><a href="#sectionC">SectionC</a></li>
      </ol>
    </li>
    <li><a>LessonB</a></li>
    <li><a>LessonC</a></li>
  </ol>
    
</details>
Let’s reset the list spacing in CSS:
ol {
  padding-left: 0;
  list-style-position: inside;
}
padding-left: 0 ensures that the parent list and all nested lists snap to the left side of the disclosure, minus any padding you might want to add. Don’t worry about the indentation of nested lists — we have something planned for those. list-style-position: inside ensures that the list markers snap to the side, rather than the text, causing the markers to overflow.
After that, we slap color: transparent on the ::markers of nested <li> elements since we don’t need the lesson section titles to be numbered. We’re only using nested lists for semantics, and nested numbered lists specifically because a different type of list marker (e.g., bullets) would cause vertical misalignment between the course’s lesson titles and the lesson section titles.
ol ol li::marker {
  color: transparent;
}




Finally, so that users can more easily traverse the current lesson, we’ll dim all list items that aren’t related to the current lesson. It’s a form of emphasizing something by de-emphasizing others:
details {
  /* The default color */
  color: light-dark(hsl(var(--hs) 90%), hsl(var(--hs) 10%));
}

/* <li>s without .active that’re direct descendants of the parent <ol> */
ol:has(ol) > li:not(.active) {
  /* A less intense color */
  color: light-dark(hsl(var(--hs) 80%), hsl(var(--hs) 20%));
}

/* Also */
a {
  color: inherit;
}
One more thing… those anchor links scroll users to specific headings, right? So, putting scroll-behavior: smooth on the root to enables smooth scrolling between them. And that percentage-read tracker that we created? Yep, that’ll work here as well.
:root {
  scroll-behavior: smooth; /* Smooth anchor scrolling */
  scroll-padding-top: 20px; /* A scroll offset, basically */
}
Transitioning the disclosure
Next, let’s transition the opening and closing of the ::details-content pseudo-element. By default, the <details> element snaps open and closed when clicked, but we want a smooth transition instead. Geoff recently detailed how to do this in a comprehensive set of notes about the <details> element, but we’ll break it down together.
First, we’ll transition from height: 0 to height: auto. This is a brand-new feature in CSS! We start by “opting into” the feature at the root level with interpolate-size: allow-keywords`:
:root {
  interpolate-size: allow-keywords;
}




I recommend setting overflow-y: clip on details::details-content to prevent the content from overflowing the disclosure as it transitions in and out:
details::details-content {
  overflow-y: clip;
}




Another option is sliding the content out and then fading it in (and vice-versa), but you’ll need to be quite specific about the transition’s setup.
First, for the “before” and “after” states, you’ll need to target both details[open] and details:not([open]), because vaguely targeting details and then overwriting the transitioning styles with details[open] doesn’t allow us to reverse the transition.
After that, slap the same transition on both but with different values for the transition delays so that the fade happens after when opening but before when closing.
Finally, you’ll also need to specify which properties are transitioned. We could simply put the all keyword in there, but that is neither performant nor allows us to set the transition durations and delays for each property. So we’ll list them individually instead in a comma-separated list. Notice that we’re specifically transitioning the content-visibility and using the allow-discrete keyword because it is a discrete property. this is why we opted into interpolate-size: allow-keywords earlier.
details:not([open])::details-content {
  height: 0;
  opacity: 0;
  padding: 0 42px;
  filter: blur(10px);
  border-top: 0 solid light-dark(hsl(var(--hs) 30%), hsl(var(--hs) 70%));
  transition:
    height 300ms 300ms, 
    padding-top 300ms 300ms, 
    padding-bottom 300ms 300ms, 
    content-visibility 300ms 300ms allow-discrete, 
    filter 300ms 0ms, 
    opacity 300ms 0ms;
}

details[open]::details-content {
  height: auto;
  opacity: 1;
  padding: 42px;
  filter: blur(0);
  border-top: 1px solid light-dark(hsl(var(--hs) 30%), hsl(var(--hs) 70%));
  transition: 
    height 300ms 0ms, 
    padding-top 300ms 0ms, 
    padding-bottom 300ms 0ms, 
    content-visibility 300ms 0ms allow-discrete, 
    filter 300ms 300ms, 
    opacity 300ms 300ms;
}
Giving the summary a label and icons
Preceding the current lesson’s title, percentage read, and dark mode toggle, the <summary> element needs a label that helps describe what it does. I went with “Navigate course” and included an aria-label saying the same thing so that screen readers didn’t announce all that other stuff.
<details>
  <summary aria-label="Navigate course">
    <span>
      <i></i>
      <span>Navigate course</span>
    </span>
    
    

  </summary>
  
  
</details>
In addition, the summary gets display: flex so that we can easily separate the three sections with a gap, which also removes the summary’s default marker, allowing you to use your own. (Again, I’m using Font Awesome in the demo.)
i::before {
  width: 1.25em;
  font-style: normal;
  display: inline-block;
  font-family: "Font Awesome 6 Free";
}

details i::before {
  content: "\f0cb"; /* fa-list-ol */
}

details[open] i::before {
  content: "\f00d"; /* fa-xmark */
}


/* For older Safari */
summary::-webkit-details-marker {
   display: none;
}
And finally, if you’re pro-cursor: pointer for most interactive elements, you’ll want to use it on the summary and manually make sure that the checkbox’s label inherits it, as it doesn’t do that automatically.
summary {
  cursor: pointer;
}

label {
  cursor: inherit;
}
Giving the disclosure an auto-closure mechanism
A tiny bit of JavaScript couldn’t hurt though, could it? I know I said this is a no-JavaScript deal, but this one-liner will automatically close the disclosure when the mouse leaves it:
document.querySelector("details").addEventListener("mouseleave", e => e.target.removeAttribute("open"));
Annoying or useful? I’ll let you decide.
Setting the preferred color scheme automatically
Setting the preferred color scheme automatically is certainly useful, but if you like to avoid JavaScript wherever possible, I don’t think users will be too mad for not offering this feature. Either way, the following conditional snippet checks if the user’s preferred color scheme is “dark” by evaluating the relevant CSS media query (prefers-color-scheme: dark) using window.matchMedia and matches. If the condition is met, the checkbox gets checked, and then the CSS handles the rest.
if (window.matchMedia("prefers-color-scheme: dark").matches) {
  document.querySelector("input[type=checkbox]").checked = true;
}
Recap
This has been fun! It’s such a blessing we can combine all of these cutting-edge CSS features, not just into one project but into a single component. To summarize, that includes:
a course navigator that shows the current lesson, all other lessons, and smooth scrolls between the different headings,
a percentage-scrolled tracker that shows the amount read in plain text and as a conic gradient… pie chart,
a light/dark-mode toggle (with some optional JavaScript that detects the preferred color scheme), and it is
all packed into a single, floating, animated, native disclosure component.
The newer CSS features we covered in the process:
Scroll-driven animations
interpolate-size: allow-keywords for transitioning between 0 and auto
smooth scrolling by way of scroll-behavior: smooth
dark mode magic using the light-dark() function
a progress chart made with a conic-gradient()
styling the ::details-content pseudo-element
animating the <details> element
Thanks to Jhey for the inspiration! If you’re not following Jhey on Bluesky or X, you’re missing out. You can also see his work on CodePen, some of which he has talked about right here on CSS-Tricks.
Case Study: Combining Cutting-Edge CSS Features Into a “Course Navigation” Component originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Having been tasked with creating a UI component for navigating the content of an online course, Daniel found himself neck-deep in a pool of new CSS features that he wound up using on the project.
Case Study: Combining Cutting-Edge CSS Features Into a “Course Navigation” Component originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Case Study: Combining Cutting-Edge CSS Features Into a “Course Navigation” Component

<p>There’s a bit of a blind spot when working with CSS logical properties concerning shorthands.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/support-logical-shorthands-in-css/">Support Logical Shorthands in 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>There’s a bit of a blind spot when working with CSS logical properties concerning shorthands. Miriam explains:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>Logical properties are a great way to optimize our sites in advance, without any real effort.</p>



<p>But what if we want to set multiple properties at once? This is where shorthands like&nbsp;<code>margin</code>&nbsp;and&nbsp;<code>padding</code>&nbsp;become useful. But they are currently limited to setting physical dimension. Logical properties are great, but they still feel like a second-class feature of the language.</p>



<p>There are a few 2-value shorthands that have been implemented, like&nbsp;<code>margin-block</code>&nbsp;for setting both the&nbsp;<code>-block-start</code>&nbsp;and&nbsp;<code>-block-end</code>margins. I find those extremely useful and concise. But the existing 4-value shorthands feel stuck in the past. It’s surprising that a&nbsp;<code>size</code> shorthand can’t set the&nbsp;<code>inline-size</code>, and the&nbsp;<code>inset</code>&nbsp;shorthand doesn’t include&nbsp;<code>inset-block-start</code>. Is there any way to update those shorthand properties so that they can be used to set logical dimensions?</p>
</blockquote>



<p>She ends with the money question, whether we can do anything about it. We’re currently in a position of having to choose between supporting flow-relative terms like <code>block-start</code> and <code>inline-start</code> with longhand properties and the ergonomic benefits of writing shorthand properties that are evaluated as physical terms like <code>top</code>, <code>bottom</code>, <code>left</code>, and <code>right</code>. Those of us writing CSS for a while likely have the muscle memory to adapt accordingly, but it’s otherwise a decision that has real consequences, particularly for multi-lingual sites.</p>



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



<p>Note that Miriam says this is something the CSS Working Group has been working on since 2017. And there’s a little momentum to pick it up and do something about it. The first thing you can do is <a href="https://opencollective.com/oddbird-open-source/contribute/css-logical-shorthands-86141" rel="noopener">support Miriam’s work</a> — everything she does with the CSS Working Group (and it’s a lot) is a labor of love and relies on sponsorships, so chipping in is one way to push things forward.</p>



<p>The other thing you can do is chime into <a href="https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897" rel="noopener">Miriam’s proposal</a> that she published in 2021. I think it’s a solid idea. We can’t simply switch from physical to flow-relative terms in shorthand properties without triggering compatibility issues, so having some sort of higher-level instruction for CSS at the top of the stylesheet, perhaps as an at-rule that specifies which “mode” we’re in.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">&lt;coordinate-mode> = [ logical | physical ] or [ relative | absolute ] or ...

@mode &lt;coordinate-mode>; /* must come after @import and before any style rules */

@mode &lt;coordinate-mode> { &lt;stylesheet> }

selector {
  property: value  !&lt;coordinate-mode>;
}</code></pre>



<p>Perhaps naming aside, it seems pretty reasonable, eh?</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/support-logical-shorthands-in-css/">Support Logical Shorthands in 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>


There’s a bit of a blind spot when working with CSS logical properties concerning shorthands. Miriam explains:
Logical properties are a great way to optimize our sites in advance, without any real effort.
But what if we want to set multiple properties at once? This is where shorthands like margin and padding become useful. But they are currently limited to setting physical dimension. Logical properties are great, but they still feel like a second-class feature of the language.
There are a few 2-value shorthands that have been implemented, like margin-block for setting both the -block-start and -block-endmargins. I find those extremely useful and concise. But the existing 4-value shorthands feel stuck in the past. It’s surprising that a size shorthand can’t set the inline-size, and the inset shorthand doesn’t include inset-block-start. Is there any way to update those shorthand properties so that they can be used to set logical dimensions?
She ends with the money question, whether we can do anything about it. We’re currently in a position of having to choose between supporting flow-relative terms like block-start and inline-start with longhand properties and the ergonomic benefits of writing shorthand properties that are evaluated as physical terms like top, bottom, left, and right. Those of us writing CSS for a while likely have the muscle memory to adapt accordingly, but it’s otherwise a decision that has real consequences, particularly for multi-lingual sites.




Note that Miriam says this is something the CSS Working Group has been working on since 2017. And there’s a little momentum to pick it up and do something about it. The first thing you can do is support Miriam’s work — everything she does with the CSS Working Group (and it’s a lot) is a labor of love and relies on sponsorships, so chipping in is one way to push things forward.
The other thing you can do is chime into Miriam’s proposal that she published in 2021. I think it’s a solid idea. We can’t simply switch from physical to flow-relative terms in shorthand properties without triggering compatibility issues, so having some sort of higher-level instruction for CSS at the top of the stylesheet, perhaps as an at-rule that specifies which “mode” we’re in.
<coordinate-mode> = [ logical | physical ] or [ relative | absolute ] or ...

@mode <coordinate-mode>; /* must come after @import and before any style rules */

@mode <coordinate-mode> { <stylesheet> }

selector {
  property: value  !<coordinate-mode>;
}
Perhaps naming aside, it seems pretty reasonable, eh?
Support Logical Shorthands in CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

There’s a bit of a blind spot when working with CSS logical properties concerning shorthands.
Support Logical Shorthands in CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Support Logical Shorthands in CSS

<p>I’ve used border-image regularly. Yet, it remains one of the most underused CSS tools, and I can’t, for the life of me, figure out why. Is it possible that people steer clear of border-image because its syntax is awkward and unintuitive? Perhaps it’s because most explanations don’t solve the type of creative implementation problems that most people need to solve. Most likely, it’s both.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/revisiting-css-border-image/">Revisiting CSS border-image</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>


In my last article on “Revisiting CSS Multi-Column Layout”, I mentioned that almost twenty years have flown by since I wrote my first book, Transcending CSS. In it, I explained how and why to use what were, at the time, an emerging CSS property.
Ten years later, I wrote the Hardboiled Web Design Fifth Anniversary Edition, covering similar ground and introducing the new CSS border-image property.
Hint: I published an updated version, Transcending CSS Revisited which is free to read online. Hardboiled Web Design is available from my bookshop.
I was very excited about the possibilities this new property would offer. After all, we could now add images to the borders of any element, even table cells and rows (unless their borders had been set to collapse).
Since then, I’ve used border-image regularly. Yet, it remains one of the most underused CSS tools, and I can’t, for the life of me, figure out why. Is it possible that people steer clear of border-image because its syntax is awkward and unintuitive? Perhaps it’s because most explanations don’t solve the type of creative implementation problems that most people need to solve. Most likely, it’s both.




I’ve recently been working on a new website for Emmy-award-winning game composer Mike Worth. He hired me to create a highly graphical design that showcases his work, and I used border-image throughout.
Design by Andy Clarke, Stuff & Nonsense. Mike Worth’s website will launch in April 2025, but you can see examples from this article on CodePen.


A brief overview of properties and values
First, here’s a short refresher. Most border-image explanations begin with this highly illuminating code snippet:
border-image: \[source\] [slice]/\[width]/[outset\] [repeat]
This is shorthand for a set of border-image properties, but it’s best to deal with properties individually to grasp the concept more easily.
A border-image’s source
I’ll start with the source of the bitmap or vector format image or CSS gradient to be inserted into the border space:
border-image-source: url('/img/scroll.png');
When I insert SVG images into a border, I have several choices as to how. I could use an external SVG file:
border-image-source: url('/img/scroll.svg');
Or I might convert my SVG to data URI using a tool like Base64.Guru although, as both SVG and HTML are XML-based, this isn’t recommended:
border-image-source: url('data:image/svg+xml;base64,…');
Instead, I can add the SVG code directly into the source URL value and save one unnecessary HTTP request:
border-image-source: url('data:image/svg+xml;utf8,…');
Finally, I could insert an entirely CSS-generated conical, linear, or radial gradient into my border:
border-image-source: conical-gradient(…);
Tip: It’s useful to remember that a browser renders a border-image above an element’s background and box-shadow but below its content. More on that a little later.
Slicing up a border-image
Now that I’ve specified the source of a border image, I can apply it to a border by slicing it up and using the parts in different positions around an element. This can be the most baffling aspect for people new to border-image.
Most border-image explanations show an example where the pieces will simply be equally-sized, like this:




However, a border-image can be developed from any shape, no matter how complex or irregular.
Instead of simply inserting an image into a border and watching it repeat around an element, invisible cut-lines slice up a border-image into nine parts. These lines are similar to the slice guides found in graphics applications. The pieces are, in turn, inserted into the nine regions of an element’s border.




The border-image-slice property defines the size of each slice by specifying the distance from each edge of the image. I could use the same distance from every edge:
border-image-slice: 65
I can combine top/bottom and left/right values:
border-image-slice: 115 65;
Or, I can specify distance values for all four cut-lines, running clockwise: top, right, bottom, left:
border-image-slice: 65 65 115 125;
The top-left of an image will be used on the top-left corner of an element’s border. The bottom-right will be used on the bottom-right, and so on.




I don’t need to add units to border-image-slice values when using a bitmap image as the browser correctly assumes bitmaps use pixels. The SVG viewBox makes using them a little different, so I also prefer to specify their height and width:
<svg height="600px" width="600px">…</svg>
Don’t forget to set the widths of these borders, as without them, there will be nowhere for a border’s image to display:
border-image-width: 65px 65px 115px 125px;
Filling in the center
So far, I’ve used all four corners and sides of my image, but what about the center? By default, the browser will ignore the center of an image after it’s been sliced. But I can put it to use by adding the fill keyword to my border-image-slice value:
border-image-slice: 65px 65px 115px 125px fill;
Setting up repeats
With the corners of my border images in place, I can turn my attention to the edges between them. As you might imagine, the slice at the top of an image will be placed on the top edge. The same is true of the right, bottom, and left edges. In a flexible design, we never know how wide or tall these edges will be, so I can fine-tune how images will repeat or stretch when they fill an edge.




Stretch: When a sliced image is flat or smooth, it can stretch to fill any height or width. Even a tiny 65px slice can stretch to hundreds or thousands of pixels without degrading.
border-image-repeat: stretch;
Repeat: If an image has texture, stretching it isn’t an option, so it can repeat to fill any height or width.
border-image-repeat: repeat;
Round: If an image has a pattern or shape that can’t be stretched and I need to match the edges of the repeat, I can specify that the repeat be round. A browser will resize the image so that only whole pieces display inside an edge.
border-image-repeat: round;
Space: Similar to round, when using the space property, only whole pieces will display inside an edge. But instead of resizing the image, a browser will add spaces into the repeat.
border-image-repeat: space;
When I need to specify a separate stretch, repeat, round, or space value for each edge, I can use multiple keywords:
border-image-repeat: stretch round;
Outsetting a border-image
There can be times when I need an image to extend beyond an element’s border-box. Using the border-image-outset property, I can do just that. The simplest syntax extends the border image evenly on all sides by 10px:
border-image-outset: 10px;
Of course, there being four borders on every element, I could also specify each outset individually:
border-image-outset: 20px 10px; 
/* or */
border-image-outset: 20px 10px 0;
border-image in action
Mike Worth is a video game composer who’s won an Emmy for his work. He loves ’90s animation — especially Disney’s Duck Tales — and he asked me to create custom artwork and develop a bold, retro-style design.




My challenge when developing for Mike was implementing my highly graphical design without compromising performance, especially on mobile devices. While it’s normal in CSS to accomplish the same goal in several ways, here, border-image often proved to be the most efficient.
Decorative buttons
The easiest and most obvious place to start was creating buttons reminiscent of stone tablets with chipped and uneven edges.




I created an SVG of the tablet shape and added it to my buttons using border-image:
button {
  border-image-repeat: stretch;
  border-image-slice: 10 10 10 10 fill;
  border-image-source: url('data:image/svg+xml;utf8,…');
  border-image-width: 20px;
}
I set the border-image-repeat on all edges to stretch and the center slice to fill so these stone tablet-style buttons expand along with their content to any height or width.
CodePen Embed Fallback
Article scroll
I want every aspect of Mike’s website design to express his brand. That means continuing the ’90s cartoon theme in his long-form content by turning it into a paper scroll.




The markup is straightforward with just a single article element:
<article>
  
</article>
But, I struggled to decide how to implement the paper effect. My first thought was to divide my scroll into three separate SVG files (top, middle, and bottom) and use pseudo-elements to add the rolled up top and bottom parts of the scroll. I started by applying a vertically repeating graphic to the middle of my article:
article {
  padding: 10rem 8rem;
  box-sizing: border-box;
  /* Scroll middle */
  background-image: url('data:image/svg+xml;utf8,…');
  background-position: center;
  background-repeat: repeat-y;
  background-size: contain;
}
Then, I added two pseudo-elements, each containing its own SVG content:
article:before {
  display: block;
  position: relative;
  top: -30px;
  /* Scroll top */
  content: url('data:image/svg+xml;utf8,…');
}

article:after {
  display: block;
  position: relative;
  top: 50px;
  /* Scroll bottom */
  content: url('data:image/svg+xml;utf8,…');
}
While this implementation worked as expected, using two pseudo-elements and three separate SVG files felt clumsy. However, using border-image, one SVG, and no pseudo-elements feels more elegant and significantly reduces the amount of code needed to implement the effect.
I started by creating an SVG of the complete tablet shape:




And I worked out the position of the four cut-lines:




Then, I inserted this single SVG into my article’s border by first selecting the source, slicing the image, and setting the top and bottom edges to stretch and the left and right edges to round:
article {
  border-image-slice: 150 95 150 95 fill;
  border-image-width: 150px 95px 150px 95px;
  border-image-repeat: stretch round;
  border-image-source: url('data:image/svg+xml;utf8,…');
}
The result is a flexible paper scroll effect which adapts to both the viewport width and any amount or type of content.
CodePen Embed Fallback
Home page overlay
My final challenge was implementing the action-packed graphic I’d designed for Mike Worth’s home page. This contains a foreground SVG featuring Mike’s orangutan mascot and a zooming background graphic:




<section>
  
  <div>...</div>

  
  <div>
    <svg>…</svg>
  </div>
</section>
I defined the section as a positioning context for its children:
section {
  position: relative;
}
Then, I absolutely positioned a pseudo-element and added the zooming graphic to its background:
section:before {
  content: "";
  position: absolute;
  z-index: -1;
  background-image: url('data:image/svg+xml;utf8,…');
  background-position: center center;
  background-repeat: no-repeat;
  background-size: 100%;
}
I wanted this graphic to spin and add subtle movement to the panel, so I applied a simple CSS animation to the pseudo-element:
@keyframes spin-bg {
  from { transform: rotate(0deg); }
  to { transform: rotate(360deg); }
}

section:before {
  animation: spin-bg 240s linear infinite;
}
Next, I added a CSS mask to fade the edges of the zooming graphic into the background. The CSS mask-image property specifies a mask layer image, which can be a PNG image, an SVG image or mask, or a CSS gradient:
section:before {
  mask-image: radial-gradient(circle, rgb(0 0 0) 0%, rgb(0 0 0 / 0) 60%);
  mask-repeat: no-repeat;
}
At this point, you might wonder where a border image could be used in this design. To add more interactivity to the graphic, I wanted to reduce its opacity and change its color — by adding a colored gradient overlay — when someone interacts with it. One of the simplest, but rarely-used, methods for applying an overlay to an element is using border-image. First, I added a default opacity and added a brief transition:
section:before {
  opacity: 1;
  transition: opacity .25s ease-in-out;
}
Then, on hover, I reduced the opacity to .5 and added a border-image:
section:hover::before {
  opacity: .5;
  border-image: fill 0 linear-gradient(rgba(0,0,255,.25),rgba(255,0,0,1));
}
You may ponder why I’ve not used the other border-image values I explained earlier, so I’ll dissect that declaration. First is the border-image-slice value, where zero pixels ensures that the eight corners and edges stay empty. The fill keyword ensures the middle section is filled with the linear gradient. Second, the border-image-source is a CSS linear gradient that blends blue into red. A browser renders this border-image above the background but behind the content.
CodePen Embed Fallback
Conclusion: You should take a fresh look at border-image
The border-image property is a powerful, yet often overlooked, CSS tool that offers incredible flexibility. By slicing, repeating, and outsetting images, you can create intricate borders, decorative elements, and even dynamic overlays with minimal code.
In my work for Mike Worth’s website, border-image proved invaluable, improving performance while maintaining a highly graphical aesthetic. Whether used for buttons, interactive overlays, or larger graphic elements, border-image can create visually striking designs without relying on extra markup or multiple assets.
If you’ve yet to experiment with border-image, now’s the time to revisit its potential and add it to your design toolkit.
Hint: Mike Worth’s website will launch in April 2025, but you can see examples from this article on CodePen.
About Andy Clarke
Often referred to as one of the pioneers of web design, Andy Clarke has been instrumental in pushing the boundaries of web design and is known for his creative and visually stunning designs. His work has inspired countless designers to explore the full potential of product and website design.
Andy’s written several industry-leading books, including Transcending CSS, Hardboiled Web Design, and Art Direction for the Web. He’s also worked with businesses of all sizes and industries to achieve their goals through design.
Visit Andy’s studio, Stuff & Nonsense, and check out his Contract Killer, the popular web design contract template trusted by thousands of web designers and developers.


Revisiting CSS border-image originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I’ve used border-image regularly. Yet, it remains one of the most underused CSS tools, and I can’t, for the life of me, figure out why. Is it possible that people steer clear of border-image because its syntax is awkward and unintuitive? Perhaps it’s because most explanations don’t solve the type of creative implementation problems that most people need to solve. Most likely, it’s both.
Revisiting CSS border-image originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Revisiting CSS border-image

<p>I&#8217;ve seen a handful of recent posts talking about the utility of the <code>:is()</code> relational pseudo-selector. No need to delve into the details other than to say it can help make compound selectors a lot more readable.</p>
<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">:is(section, article, aside, </code></pre>
<p>&#8230;</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/quick-reminder-that-is-and-where-are-basically-the-same-with-one-key-difference/">Quick Reminder That :is() and :where() Are Basically the Same With One Key Difference</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&#8217;ve seen a handful of recent posts talking about the utility of the <code>:is()</code> relational pseudo-selector. No need to delve into the details other than to say it can help make compound selectors a lot more readable.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">:is(section, article, aside, nav) :is(h1, h2, h3, h4, h5, h6) {
  color: #BADA55;
}

/* ... which would be the equivalent of: */
section h1, section h2, section h3, section h4, section h5, section h6, 
article h1, article h2, article h3, article h4, article h5, article h6, 
aside h1, aside h2, aside h3, aside h4, aside h5, aside h6, 
nav h1, nav h2, nav h3, nav h4, nav h5, nav h6 {
  color: #BADA55;
}</code></pre>



<p>There&#8217;s just one catch: the specificity. The selector&#8217;s specificity matches the most specific selector in the function&#8217;s arguments. That&#8217;s not a big deal when working with a relatively flat style structure containing mostly element and class selectors, but if you toss an ID in there, then that&#8217;s the specificity you&#8217;re stuck with.</p>



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



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Specificity: 0 0 1 */
:is(h1, h2, h3, h4, h5, h6) {
  color: #BADA55;
}

/* Specificity: 1 0 0 */
:is(h1, h2, h3, h4, h5, h6, #id) {
  color: #BADA55;
}</code></pre>



<p>That can be a neat thing! For example, you might want to <a href="https://geoffgraham.me/the-new-css-important/" rel="noopener">intentionally toss a made-up ID in there to force a style</a> the same way you might do with the <code>!important</code> keyword.</p>



<p>What if you don&#8217;t want that? Some articles suggest nesting selectors instead which is cool but not quite with the same nice writing ergonomics.</p>



<p> There&#8217;s where I want to point to the <code>:where()</code> selector instead! It&#8217;s the exact same thing as <code>:is()</code> but without the specificity baggage. <strong>It always carries a specificity score of zero.</strong> You might even think of it as a sort of specificity reset.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Specificity: 0 0 0 */
:where(h1, h2, h3, h4, h5, h6) {
  color: #BADA55;
}

/* Specificity: 0 0 0 */
:where(h1, h2, h3, h4, h5, h6, #id) {
  color: #BADA55;
}</code></pre>



<p>So, is there a certain selector hijacking your <code>:is()</code> specificity? You might want <code>:where()</code> instead.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/quick-reminder-that-is-and-where-are-basically-the-same-with-one-key-difference/">Quick Reminder That :is() and :where() Are Basically the Same With One Key Difference</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’ve seen a handful of recent posts talking about the utility of the :is() relational pseudo-selector. No need to delve into the details other than to say it can help make compound selectors a lot more readable.
:is(section, article, aside, nav) :is(h1, h2, h3, h4, h5, h6) {
  color: #BADA55;
}

/* ... which would be the equivalent of: */
section h1, section h2, section h3, section h4, section h5, section h6, 
article h1, article h2, article h3, article h4, article h5, article h6, 
aside h1, aside h2, aside h3, aside h4, aside h5, aside h6, 
nav h1, nav h2, nav h3, nav h4, nav h5, nav h6 {
  color: #BADA55;
}
There’s just one catch: the specificity. The selector’s specificity matches the most specific selector in the function’s arguments. That’s not a big deal when working with a relatively flat style structure containing mostly element and class selectors, but if you toss an ID in there, then that’s the specificity you’re stuck with.




/* Specificity: 0 0 1 */
:is(h1, h2, h3, h4, h5, h6) {
  color: #BADA55;
}

/* Specificity: 1 0 0 */
:is(h1, h2, h3, h4, h5, h6, #id) {
  color: #BADA55;
}
That can be a neat thing! For example, you might want to intentionally toss a made-up ID in there to force a style the same way you might do with the !important keyword.
What if you don’t want that? Some articles suggest nesting selectors instead which is cool but not quite with the same nice writing ergonomics.
 There’s where I want to point to the :where() selector instead! It’s the exact same thing as :is() but without the specificity baggage. It always carries a specificity score of zero. You might even think of it as a sort of specificity reset.
/* Specificity: 0 0 0 */
:where(h1, h2, h3, h4, h5, h6) {
  color: #BADA55;
}

/* Specificity: 0 0 0 */
:where(h1, h2, h3, h4, h5, h6, #id) {
  color: #BADA55;
}
So, is there a certain selector hijacking your :is() specificity? You might want :where() instead.
Quick Reminder That :is() and :where() Are Basically the Same With One Key Difference originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I’ve seen a handful of recent posts talking about the utility of the :is() relational pseudo-selector. No need to delve into the details other than to say it can help make compound selectors a lot more readable.
:is(section, article, aside, 
…
Quick Reminder That :is() and :where() Are Basically the Same With One Key Difference originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Quick Reminder That :is() and :where() Are Basically the Same With One Key Difference

<p>Going from the most basic ways to style lists directly in HTML to advanced customization techniques that are even capable of making things that aren't lists look like lists.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/styling-counters-in-css/">Styling Counters in 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>


Going from the most basic ways to style lists directly in HTML to advanced customization techniques that are even capable of making things that aren't lists look like lists.
Styling Counters in CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Styling Counters in CSS

<p>Scott Jehl released a course called Web Components Demystified. This is my full set of notes from Scott's course. You'll still want to take the course on your own, and I encourage you to because Scott is an excellent teacher who makes all of this stuff extremely accessible, even to noobs like me.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/web-components-demystified/">Web Components Demystified</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>


Scott Jehl released a course called Web Components Demystified. This is my full set of notes from Scott's course. You'll still want to take the course on your own, and I encourage you to because Scott is an excellent teacher who makes all of this stuff extremely accessible, even to noobs like me.
Web Components Demystified originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Web Components Demystified

<p>With Astro, we can generate most of our site during our build, but have a small bit of server-side code that can handle search functionality using something like Fuse.js. In this demo, we’ll use Fuse to search through a set of personal “bookmarks” that are generated at build time, but return back proper results from a server call.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/powering-search-with-astro-actions-and-fuse-js/">Powering Search With Astro Actions and Fuse.js</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>


With Astro, we can generate most of our site during our build, but have a small bit of server-side code that can handle search functionality using something like Fuse.js. In this demo, we’ll use Fuse to search through a set of personal “bookmarks” that are generated at build time, but return back proper results from a server call.
Powering Search With Astro Actions and Fuse.js originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Powering Search With Astro Actions and Fuse.js

<p>The videos from Smashing Magazine's recent event on accessibility were just posted the other day. I was invited to host the panel discussion with the speakers, including a couple of personal heroes of mine, Stéphanie Walter and Sarah Fossheim. But I was just as stoked to meet Kardo Ayoub who shared his deeply personal story as a designer with a major visual impairment.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/smashing-meets-accessibility/">Smashing Meets Accessibility</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 videos from <a href="https://smashingconf.com/meets-accessibility" rel="noopener">Smashing Magazine&#8217;s recent event on accessibility</a> were just posted the other day. I was invited to host the panel discussion with the speakers, including a couple of personal heroes of mine, <a href="https://stephaniewalter.design" rel="noopener">Stéphanie Walter</a> and <a href="https://fossheim.io" rel="noopener">Sarah Fossheim</a>. But I was just as stoked to meet <a href="https://www.kardoayoub.com" rel="noopener">Kardo Ayoub</a> who shared his deeply personal story as a designer with a major visual impairment.</p>



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



<p>I&#8217;ll drop the video here:</p>



<iframe loading="lazy" width="560" height="315" src="https://www.youtube.com/embed/Ej0mvbTXCaI?si=uL9xiePLc4IdJhR1" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>



<p>I&#8217;ll be the first to admit that I had to hold back my emotions as Kardo detailed what led to his impairment, the shock that came of it, and how he has beaten the odds to not only be an effective designer, but a real leader in the industry. It&#8217;s well worth watching his full presentation, <a href="https://www.youtube.com/watch?v=2vn0b7apSrs" rel="noopener">which is also available on YouTube</a> alongside the full presentations from <a href="https://www.youtube.com/watch?v=2juq00vrvl0" rel="noopener">Stéphanie</a> and <a href="https://www.youtube.com/watch?v=z6jdEqz7qf8" rel="noopener">Sarah</a>.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/smashing-meets-accessibility/">Smashing Meets Accessibility</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 videos from Smashing Magazine’s recent event on accessibility were just posted the other day. I was invited to host the panel discussion with the speakers, including a couple of personal heroes of mine, Stéphanie Walter and Sarah Fossheim. But I was just as stoked to meet Kardo Ayoub who shared his deeply personal story as a designer with a major visual impairment.




I’ll drop the video here:




I’ll be the first to admit that I had to hold back my emotions as Kardo detailed what led to his impairment, the shock that came of it, and how he has beaten the odds to not only be an effective designer, but a real leader in the industry. It’s well worth watching his full presentation, which is also available on YouTube alongside the full presentations from Stéphanie and Sarah.
Smashing Meets Accessibility originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The videos from Smashing Magazine's recent event on accessibility were just posted the other day. I was invited to host the panel discussion with the speakers, including a couple of personal heroes of mine, Stéphanie Walter and Sarah Fossheim. But I was just as stoked to meet Kardo Ayoub who shared his deeply personal story as a designer with a major visual impairment.
Smashing Meets Accessibility originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Smashing Meets Accessibility

<p>In this second article of a two-part series, Temani Afif demonstrates an alternative approach to creating the star rating component from the first article using experimental scroll-driven animations rather than using the border-image property.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/a-css-only-star-rating-component-and-more-part-2/">A CSS-Only Star Rating Component and More! (Part 2)</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>


In the last article, we created a CSS-only star rating component using the CSS mask and border-image properties, as well as the newly enhanced attr() function. We ended with CSS code that we can easily adjust to create component variations, including a heart rating and volume control.
This second article will study a different approach that gives us more flexibility. Instead of the border-image trick we used in the first article, we will rely on scroll-driven animations!




Here is the same star rating component with the new implementation. And since we’re treading in experimental territory, you’ll want to view this in Chrome 115+ while we wait for Safari and Firefox support:
CodePen Embed Fallback
Do you spot the difference between this and the final demo in the first article? This time, I am updating the color of the stars based on how many of them are selected — something we cannot do using the border-image trick!
I highly recommend you read the first article before jumping into this second part if you missed it, as I will be referring to concepts and techniques that we explored over there.
One more time: At the time of writing, only Chrome 115+ and Edge 115+ fully support the features we will be using in this article, so please use either one of those as you follow along.



Why scroll-driven animations?
You might be wondering why we’re talking about scroll-driven animation when there’s nothing to scroll to in the star rating component. Scrolling? Animation? It’s even more confusing when you read the MDN explainer for scroll-driven animations:
It allows you to animate property values based on a progression along a scroll-based timeline instead of the default time-based document timeline. This means that you can animate an element by scrolling a scrollable element, rather than just by the passing of time.
But if you keep reading you will see that we have two types of scroll-based timelines: scroll progress timelines and view progress timelines. In our case, we are going to use the second one; a view progress timeline, and here is how MDN describes it:
You progress this timeline based on the change in visibility of an element (known as the subject) inside a scroller. The visibility of the subject inside the scroller is tracked as a percentage of progress — by default, the timeline is at 0% when the subject is first visible at one edge of the scroller, and 100% when it reaches the opposite edge.
You can check out the CSS-Tricks almanac definition for view-timeline-name while you’re at it for another explanation.
Things start to make more sense if we consider the thumb element as the subject and the input element as the scroller. After all, the thumb moves within the input area, so its visibility changes. We can track that movement as a percentage of progress and convert it to a value we can use to style the input element. We are essentially going to implement the equivalent of document.querySelector("input").value in JavaScript but with vanilla CSS!
The implementation
Now that we have an idea of how this works, let’s see how everything translates into code.
@property --val {
  syntax: "<number>";
  inherits: true;
  initial-value: 0; 
}

input[type="range"] {
  --min: attr(min type(<number>));
  --max: attr(max type(<number>));

  timeline-scope: --val;
  animation: --val linear both;
  animation-timeline: --val;
  animation-range: entry 100% exit 0%;
  overflow: hidden;
}

@keyframes --val {
  0%   { --val: var(--max) }
  100% { --val: var(--min) }
}

input[type="range"]::thumb {
  view-timeline: --val inline;
}
I know, this is a lot of strange syntax! But we will dissect each line and you will see that it’s not all that complex at the end of the day.
The subject and the scroller
We start by defining the subject, i.e. the thumb element, and for this we use the view-timeline shorthand property. From the MDN page, we can read:
The view-timeline CSS shorthand property is used to define a named view progress timeline, which is progressed through based on the change in visibility of an element (known as the subject) inside a scrollable element (scroller). view-timeline is set on the subject.
I think it’s self-explanatory. The view timeline name is --val and the axis is inline since we’re working along the horizontal x-axis.
Next, we define the scroller, i.e. the input element, and for this, we use overflow: hidden (or overflow: auto). This part is the easiest but also the one you will forget the most so let me insist on this: don’t forget to define overflow on the scroller!
I insist on this because your code will work fine without defining overflow, but the values won’t be good. The reason is that the scroller exists but will be defined by the browser (depending on your page structure and your CSS) and most of the time it’s not the one you want. So let me repeat it another time: remember the overflow property!
The animation
Next up, we create an animation that animates the --val variable between the input’s min and max values. Like we did in the first article, we are using the newly-enhanced attr() function to get those values. See that? The “animation” part of the scroll-driven animation, an animation we link to the view timeline we defined on the subject using animation-timeline. And to be able to animate a variable we register it using @property.
Note the use of timeline-scope which is another tricky feature that’s easy to overlook. By default, named view timelines are scoped to the element where they are defined and its descendant. In our case, the input is a parent element of the thumb so it cannot access the named view timeline. To overcome this, we increase the scope using timeline-scope. Again, from MDN:
timeline-scope is given the name of a timeline defined on a descendant element; this causes the scope of the timeline to be increased to the element that timeline-scope is set on and any of its descendants. In other words, that element and any of its descendant elements can now be controlled using that timeline.
Never forget about this! Sometimes everything is correctly defined but nothing is working because you forget about the scope.
There’s something else you might be wondering:
Why are the keyframes values inverted? Why is the min is set to 100% and the max set to 0%?
To understand this, let’s first take the following example where you can scroll the container horizontally to reveal a red circle inside of it.
CodePen Embed Fallback
Initially, the red circle is hidden on the right side. Once we start scrolling, it appears from the right side, then disappears to the left as you continue scrolling towards the right. We scroll from left to right but our actual movement is from right to left.
In our case, we don’t have any scrolling since our subject (the thumb) will not overflow the scroller (the input) but the main logic is the same. The starting point is the right side and the ending point is the left side. In other words, the animation starts when the thumb is on the right side (the input’s max value) and will end when it’s on the left side (the input’s min value).
The animation range
The last piece of the puzzle is the following important line of code:
animation-range: entry 100% exit 0%;
By default, the animation starts when the subject starts to enter the scroller from the right and ends when the subject has completely exited the scroller from the left. This is not good because, as we said, the thumb will not overflow the scroller, so it will never reach the start and the end of the animation.




To rectify this we use the animation-range property to make the start of the animation when the subject has completely entered the scroller from the right (entry 100%) and the end of the animation when the subject starts to exit the scroller from the left (exit 0%).




To summarize, the thumb element will move within input’s area and that movement is used to control the progress of an animation that animates a variable between the input’s min and max attribute values. We have our replacement for document.querySelector("input").value in JavaScript!
What’s going on with all the --val instances everywhere? Is it the same thing each time?
I am deliberately using the same --val everywhere to confuse you a little and push you to try to understand what is going on. We usually use the dashed ident (--) notation to define custom properties (also called CSS variables) that we later call with var(). This is still true but that same notation can be used to name other things as well.
In our examples we have three different things named --val:
The variable that is animated and registered using @property. It contains the selected value and is used to style the input.
The named view timeline defined by view-timeline and used by animation-timeline.
The keyframes named --val and called by animation.
Here is the same code written with different names for more clarity:
@property --val {
  syntax: "<number>";
  inherits: true;
  initial-value: 0; 
}

input[type="range"] {
  --min: attr(min type(<number>));
  --max: attr(max type(<number>));

  timeline-scope: --timeline;
  animation: value_update linear both;
  animation-timeline: --timeline;
  animation-range: entry 100% exit 0%;
  overflow: hidden;
}

@keyframes value_update {
  0%   { --val: var(--max) }
  100% { --val: var(--min) }
}

input[type="range"]::thumb {
  view-timeline: --timeine inline;
}
The star rating component
All that we have done up to now is get the selected value of the input range — which is honestly about 90% of the work we need to do. What remains is some basic styles and code taken from what we made in the first article.
If we omit the code from the previous section and the code from the previous article here is what we are left with:
input[type="range"] {
  background: 
    linear-gradient(90deg,
      hsl(calc(30 + 4 * var(--val)) 100% 56%) calc(var(--val) * 100% / var(--max)),
      #7b7b7b 0
    );
}
input[type="range"]::thumb {
  opacity: 0;
}
We make the thumb invisible and we define a gradient on the main element to color in the stars. No surprise here, but the gradient uses the same --val variable that contains the selected value to inform how much is colored in.
When, for example, you select three stars, the --val variable will equal 3 and the color stop of the first color will equal 3*100%/5 , or 60%, meaning three stars are colored in. That same color is also dynamic as I am using the hsl() function where the first argument (the hue) is a function of --val as well.
Here is the full demo, which you will want to open in Chrome 115+ at the time I’m writing this:
CodePen Embed Fallback
And guess what? This implementation works with half stars as well without the need to change the CSS. All you have to do is update the input’s attributes to work in half increments. 
<input type="range" min=".5" step=".5" max="5">
CodePen Embed Fallback
That’s it! We have our rating star component that you can easily control by adjusting the attributes.
So, should I use border-image or a scroll-driven animation?
If we look past the browser support factor, I consider this version better than the border-image approach we used in the first article. The border-image version is simpler and does the job pretty well, but it’s limited in what it can do. While our goal is to create a star rating component, it’s good to be able to do more and be able to style an input range as you want.
With scroll-driven animations, we have more flexibility since the idea is to first get the value of the input and then use it to style the element. I know it’s not easy to grasp but don’t worry about that. You will face scroll-driven animations more often in the future and it will become more familiar with time. This example will look easy to you in good time.
Worth noting, that the code used to get the value is a generic code that you can easily reuse even if you are not going to style the input itself. Getting the value of the input is independent of styling it.
Here is a demo where I am adding a tooltip to a range slider to show its value:
CodePen Embed Fallback
Many techniques are involved to create that demo and one of them is using scroll-driven animations to get the input value and show it inside the tooltip!
Here is another demo using the same technique where different range sliders are controlling different variables on the page.
CodePen Embed Fallback
And why not a wavy range slider?
CodePen Embed Fallback
This one is a bit crazy but it illustrates how far we go with styling an input range! So, even if your goal is not to create a star rating component, there are a lot of use cases where such a technique can be really useful.
Conclusion
I hope you enjoyed this brief two-part series. In addition to a star rating component made with minimal code, we have explored a lot of cool and modern features, including the attr() function, CSS mask, and scroll-driven animations. It’s still early to adopt all of these features in production because of browser support, but it’s a good time to explore them and see what can be done soon using only CSS.
Article series
A CSS-Only Star Rating Component and More! (Part 1)
A CSS-Only Star Rating Component and More! (Part 2)


A CSS-Only Star Rating Component and More! (Part 2) originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

In this second article of a two-part series, Temani Afif demonstrates an alternative approach to creating the star rating component from the first article using experimental scroll-driven animations rather than using the border-image property.
A CSS-Only Star Rating Component and More! (Part 2) originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A CSS-Only Star Rating Component and More! (Part 2)

<p>This easily qualifies as a "gotcha" in CSS and is a good reminder that the cascade doesn't know everything all at the same time. If a custom property is invalid, the cascade won't ignore it, and it gets evaluated, which invalidates the declaration.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/maybe-dont-use-custom-properties-in-shorthand-properties/">Maybe don&#8217;t use custom properties in shorthand properties</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.matuzo.at/blog/2025/invalid-custom-properties-in-shorthands" rel="noopener">Manuel Matuzović</a>:</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>That an invalid custom property invalidates the entire declaration isn&#8217;t surprising, but I didn&#8217;t consider it until I saw one of my declarations break. I guess it&#8217;s just good to know that, especially if you&#8217;re working a lot with custom properties.</p>
</blockquote>



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



<p>This easily qualifies as a &#8220;gotcha&#8221; in CSS and is a good reminder that the cascade doesn&#8217;t know everything all at the same time. If a custom property is invalid, the cascade won&#8217;t ignore it, and it gets evaluated, which invalidates the declaration. And if we set an invalid custom property on a shorthand property that combines several constituent properties — like how <code><a href="https://css-tricks.com/almanac/properties/b/background/">background</a></code> and <code><a href="https://css-tricks.com/almanac/properties/a/animation/">animation</a></code> are both shorthand for a bunch of other properties — then the entire declaration becomes invalid, including all of the implied constituents. No bueno indeed.</p>



<p>What to do, then?</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>So, maybe don&#8217;t use custom properties in shorthand properties or use custom properties but don&#8217;t use shorthand properties.</p>
</blockquote>



<p>Great advice, Manuel!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/maybe-dont-use-custom-properties-in-shorthand-properties/">Maybe don&#8217;t use custom properties in shorthand properties</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>


Manuel Matuzović:
That an invalid custom property invalidates the entire declaration isn’t surprising, but I didn’t consider it until I saw one of my declarations break. I guess it’s just good to know that, especially if you’re working a lot with custom properties.




This easily qualifies as a “gotcha” in CSS and is a good reminder that the cascade doesn’t know everything all at the same time. If a custom property is invalid, the cascade won’t ignore it, and it gets evaluated, which invalidates the declaration. And if we set an invalid custom property on a shorthand property that combines several constituent properties — like how background and animation are both shorthand for a bunch of other properties — then the entire declaration becomes invalid, including all of the implied constituents. No bueno indeed.
What to do, then?
So, maybe don’t use custom properties in shorthand properties or use custom properties but don’t use shorthand properties.
Great advice, Manuel!
Maybe don’t use custom properties in shorthand properties originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

This easily qualifies as a "gotcha" in CSS and is a good reminder that the cascade doesn't know everything all at the same time. If a custom property is invalid, the cascade won't ignore it, and it gets evaluated, which invalidates the declaration.
Maybe don’t use custom properties in shorthand properties originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Maybe don’t use custom properties in shorthand properties

<p>Preethi demonstrates how to make a user interface to group selected items using CSS Grid using two different methods: the auto-fill keyword for stable layouts and the span keyword for flexible arrangements.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/grouping-selection-list-items-together-with-css-grid/">Grouping Selection List Items Together With CSS Grid</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>Grouping selected items is a design choice often employed to help users quickly grasp which items are selected and unselected. For instance, checked-off items move up the list in to-do lists, allowing users to focus on the remaining tasks when they revisit the list.</p>



<p>We’ll design a UI that follows a similar grouping pattern. Instead of simply rearranging the list of selected items, we’ll also lay them out horizontally using CSS Grid. This further distinguishes between the selected and unselected items.</p>



<p>We’ll explore two approaches for this. One involves using <code>auto-fill</code>, which is suitable when the selected items don’t exceed the grid container’s boundaries, ensuring a stable layout. In contrast, CSS Grid’s <code>span</code> keyword provides another approach that offers greater flexibility.</p>



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



<p>The HTML is the same for both methods:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt">&lt;ul>
  &lt;li>
    &lt;label>
      &lt;input type="checkbox" />
      &lt;div class=icon>&#x1F371;&lt;/div>
      &lt;div class=text>Bento&lt;/div>
    &lt;/label>
  &lt;/li>
  &lt;li>
    &lt;label>
      &lt;input type="checkbox" />
      &lt;div class=icon>&#x1F361;&lt;/div>
      &lt;div class=text>Dangos&lt;/div>
    &lt;/label>
  &lt;/li>
  &lt;!-- more list items -->
&lt;/ul></code></pre>



<p>The markup consists of an unordered list (<code>&lt;ul></code>). However, we don’t necessarily have to use <code>&lt;ul></code> and <code>&lt;li></code> elements since the layout of the items will be determined by the CSS grid properties. Note that I am using an implicit <code>&lt;label></code> around the <code>&lt;input></code> elements mostly as a way to avoid needing an extra wrapper around things, but that <a href="https://www.w3.org/WAI/tutorials/forms/labels/#associating-labels-implicitly" rel="noopener">explicit labels are generally better supported by assistive technologies</a>.</p>


<h3 class="wp-block-heading" id="method-1-using-auto-fill-">Method 1: Using <code>auto-fill</code></h3>


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



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">ul {
  width: 250px;
  display: grid;
  gap: 14px 10px;
  grid-template-columns: repeat(auto-fill, 40px);
  justify-content: center;
  /* etc. */
}</code></pre>



<p>The <code>&lt;ul&gt;</code> element, which contains the items, has a <code>display:</code> <code>grid</code> style rule, turning it into a grid container. It also has gaps of <code>14px</code> and <code>10px</code> between its grid rows and columns. The grid content is justified (inline alignment) to <code>center</code>.</p>



<p>The <code>grid-template-columns</code> property specifies how column tracks will be sized in the grid. Initially, all items will be in a single column. However, when items are selected, they will be moved to the first row, and each selected item will be in its own column. The key part of this declaration is the <code>auto-fill</code> value.</p>



<p>The <code>auto-fill</code> value is added where the repeat count goes in the <code>repeat()</code> function. This ensures the columns repeat, with each column’s track sizing being the given size in <code>repeat()</code> (<code>40px</code> in our example), that will fit inside the grid container’s boundaries.</p>



<p>For now, let’s make sure that the list items are positioned in a single column:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">li {
  width: inherit;
  grid-column: 1;
  /* Equivalent to: 
      grid-column-start: 1;
      grid-column-end: auto; */
  /* etc. */
}</code></pre>



<p>When an item is checked, that is when an <code>&lt;li&gt;</code> element <code>:has()</code> a <code>:checked</code> checkbox, we’re selecting that. And when we do, the <code>&lt;li&gt;</code> is given a <code>grid-area</code> that puts it in the first row, and its column will be auto-placed within the grid in the first row as per the value of the <code>grid-template-columns</code> property of the grid container (<code>&lt;ul&gt;</code>). This causes the selected items to group at the top of the list and be arranged horizontally:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">li {
  width: inherit;
  grid-column: 1;
  /* etc. */
  &amp;:has(:checked) {
    grid-area: 1;
    /* Equivalent to: 
      grid-row-start: 1;
      grid-column-start: auto;
      grid-row-end: auto;
      grid-column-end: auto; */
    width: 40px;
    /* etc. */
  }
  /* etc. */
}</code></pre>



<p>And that gives us our final result! Let’s compare that with the second method I want to show you.</p>


<h3 class="wp-block-heading" id="method-2-using-the-span-keyword">Method 2: Using the <code>span</code> keyword</h3>


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



<p>We won’t be needing the <code>grid-template-columns</code> property now. Here’s the new <code>&lt;ul&gt;</code> style ruleset:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">ul {
  width: 250px;
  display: grid;
  gap: 14px 10px;
  justify-content: center;
  justify-items: center;
  /* etc. */
}</code></pre>



<p>The inclusion of <code>justify-items</code> will help with the alignment of grid items as we’ll see in a moment. Here are the updated styles for the <code>&lt;li&gt;</code> element:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">li {
  width: inherit;
  grid-column: 1 / span 6;
  /* Equivalent to: 
     grid-column-start: 1;
     grid-column-end: span 6; */
  /* etc. */
}</code></pre>



<p>As before, each item is placed in the first column, but now they also <code>span</code> six column tracks (since there are six items). This ensures that when multiple columns appear in the grid, as items are selected, the following unselected items remain in a single column under the selected items — now the unselected items span across multiple column tracks. The <code>justify-items: center</code> declaration will keep the items aligned to the center.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">li {
  width: inherit;
  grid-column: 1 / span 6;
  /* etc. */
  &amp;:has(:checked) {
    grid-area: 1;
    width: 120px;
    /* etc. */
  }
  /* etc. */
}</code></pre>



<p>The width of the selected items has been increased from the previous example, so the layout of the selection UI can be viewed for when the selected items overflow the container.</p>


<h3 class="wp-block-heading" id="selection-order">Selection order</h3>


<p>The order of selected and unselected items will remain the same as the source order. If the on-screen order needs to match the user’s selection, dynamically assign an incremental <code>order</code> value to the items as they are selected.</p>



<pre rel="JavaScript" class="wp-block-csstricks-code-block language-javascript" data-line=""><code markup="tt">onload = ()=>{
  let i=1;
  document.querySelectorAll('input').forEach((input)=>{
    input.addEventListener("click", () => {
      input.parentElement.parentElement.style.order = input.checked ? i++ : (i--, 0);
    });
  });
}</code></pre>



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


<h3 class="wp-block-heading" id="wrapping-up">Wrapping up</h3>


<p>CSS Grid helps make both approaches very flexible without a ton of configuration. By using <code>auto-fill</code> to place items on either axis (rows or columns), the selected items can be easily grouped within the grid container without disturbing the layout of the unselected items in the same container, for as long as the selected items don’t overflow the container.</p>



<p>If they do overflow the container, using the <code>span</code> approach helps maintain the layout irrespective of how long the group of selected items gets in a given axis. Some design alternatives for the UI are grouping the selected items at the end of the list, or swapping the horizontal and vertical structure.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/grouping-selection-list-items-together-with-css-grid/">Grouping Selection List Items Together With CSS Grid</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>


Grouping selected items is a design choice often employed to help users quickly grasp which items are selected and unselected. For instance, checked-off items move up the list in to-do lists, allowing users to focus on the remaining tasks when they revisit the list.
We’ll design a UI that follows a similar grouping pattern. Instead of simply rearranging the list of selected items, we’ll also lay them out horizontally using CSS Grid. This further distinguishes between the selected and unselected items.
We’ll explore two approaches for this. One involves using auto-fill, which is suitable when the selected items don’t exceed the grid container’s boundaries, ensuring a stable layout. In contrast, CSS Grid’s span keyword provides another approach that offers greater flexibility.




The HTML is the same for both methods:
<ul>
  <li>
    <label>
      <input type="checkbox" />
      <div class=icon>🍱</div>
      <div class=text>Bento</div>
    </label>
  </li>
  <li>
    <label>
      <input type="checkbox" />
      <div class=icon>🍡</div>
      <div class=text>Dangos</div>
    </label>
  </li>
  
</ul>
The markup consists of an unordered list (<ul>). However, we don’t necessarily have to use <ul> and <li> elements since the layout of the items will be determined by the CSS grid properties. Note that I am using an implicit <label> around the <input> elements mostly as a way to avoid needing an extra wrapper around things, but that explicit labels are generally better supported by assistive technologies.
Method 1: Using auto-fill
CodePen Embed Fallback
ul {
  width: 250px;
  display: grid;
  gap: 14px 10px;
  grid-template-columns: repeat(auto-fill, 40px);
  justify-content: center;
  /* etc. */
}
The <ul> element, which contains the items, has a display: grid style rule, turning it into a grid container. It also has gaps of 14px and 10px between its grid rows and columns. The grid content is justified (inline alignment) to center.
The grid-template-columns property specifies how column tracks will be sized in the grid. Initially, all items will be in a single column. However, when items are selected, they will be moved to the first row, and each selected item will be in its own column. The key part of this declaration is the auto-fill value.
The auto-fill value is added where the repeat count goes in the repeat() function. This ensures the columns repeat, with each column’s track sizing being the given size in repeat() (40px in our example), that will fit inside the grid container’s boundaries.
For now, let’s make sure that the list items are positioned in a single column:
li {
  width: inherit;
  grid-column: 1;
  /* Equivalent to: 
      grid-column-start: 1;
      grid-column-end: auto; */
  /* etc. */
}
When an item is checked, that is when an <li> element :has() a :checked checkbox, we’re selecting that. And when we do, the <li> is given a grid-area that puts it in the first row, and its column will be auto-placed within the grid in the first row as per the value of the grid-template-columns property of the grid container (<ul>). This causes the selected items to group at the top of the list and be arranged horizontally:
li {
  width: inherit;
  grid-column: 1;
  /* etc. */
  &:has(:checked) {
    grid-area: 1;
    /* Equivalent to: 
      grid-row-start: 1;
      grid-column-start: auto;
      grid-row-end: auto;
      grid-column-end: auto; */
    width: 40px;
    /* etc. */
  }
  /* etc. */
}
And that gives us our final result! Let’s compare that with the second method I want to show you.
Method 2: Using the span keyword
CodePen Embed Fallback
We won’t be needing the grid-template-columns property now. Here’s the new <ul> style ruleset:
ul {
  width: 250px;
  display: grid;
  gap: 14px 10px;
  justify-content: center;
  justify-items: center;
  /* etc. */
}
The inclusion of justify-items will help with the alignment of grid items as we’ll see in a moment. Here are the updated styles for the <li> element:
li {
  width: inherit;
  grid-column: 1 / span 6;
  /* Equivalent to: 
     grid-column-start: 1;
     grid-column-end: span 6; */
  /* etc. */
}
As before, each item is placed in the first column, but now they also span six column tracks (since there are six items). This ensures that when multiple columns appear in the grid, as items are selected, the following unselected items remain in a single column under the selected items — now the unselected items span across multiple column tracks. The justify-items: center declaration will keep the items aligned to the center.
li {
  width: inherit;
  grid-column: 1 / span 6;
  /* etc. */
  &:has(:checked) {
    grid-area: 1;
    width: 120px;
    /* etc. */
  }
  /* etc. */
}
The width of the selected items has been increased from the previous example, so the layout of the selection UI can be viewed for when the selected items overflow the container.
Selection order
The order of selected and unselected items will remain the same as the source order. If the on-screen order needs to match the user’s selection, dynamically assign an incremental order value to the items as they are selected.
onload = ()=>{
  let i=1;
  document.querySelectorAll('input').forEach((input)=>{
    input.addEventListener("click", () => {
      input.parentElement.parentElement.style.order = input.checked ? i++ : (i--, 0);
    });
  });
}
CodePen Embed Fallback
Wrapping up
CSS Grid helps make both approaches very flexible without a ton of configuration. By using auto-fill to place items on either axis (rows or columns), the selected items can be easily grouped within the grid container without disturbing the layout of the unselected items in the same container, for as long as the selected items don’t overflow the container.
If they do overflow the container, using the span approach helps maintain the layout irrespective of how long the group of selected items gets in a given axis. Some design alternatives for the UI are grouping the selected items at the end of the list, or swapping the horizontal and vertical structure.
Grouping Selection List Items Together With CSS Grid originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Preethi demonstrates how to make a user interface to group selected items using CSS Grid using two different methods: the auto-fill keyword for stable layouts and the span keyword for flexible arrangements.
Grouping Selection List Items Together With CSS Grid originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.