I have a new article up on web.dev, about CSSNestedDeclarations which is coming to all browsers.

To fix some weird quirks with CSS nesting, the CSS Working Group resolved to add the CSSNestedDeclarations interface to the CSS Nesting Specification. With this addition, declarations that come after style rules no longer shift up, among some other improvements.

These changes are available in Chrome from version 130 and are ready for testing in Firefox Nightly 132 and Safari Technology Preview 204.

Besides writing the post, I had lots of fun building this CSSRule debugger for this blogpost. It shows you what goes on behind the scenes and how your CSS gets interpreted by the CSS Engine.

Here’s a comparison of Chrome without and with CSSNestedDeclarations support. The version with CSSNestedDeclarations support clearly is better.

I cannot help but stress that this is a change that is part of the CSS Nesting spec and is one that is coming to all engines. Firefox Nightly 132 is passing all tests, and with 8/11 subtests passing Safari Technology Preview 204 still has a little bit of cleaning to do before it can ship this.

Read “CSS nesting improves with CSSNestedDeclarations” →

With @​property now being Baseline Newly Available, I thought it’d be a good time benchmark the impact – if any – it has on the performance of your CSS.

When starting to use a new CSS feature it’s important to understand its impact on the performance of your websites, whether positive or negative. With @property now in Baseline this post explores its performance impact, and things you can do to help prevent negative impact.

For this I built and open sourced the “CSS Selector Benchmark” project which I have been working on for some time now.

To benchmark the performance of CSS we built the “CSS Selector Benchmark” test suite. It is powered by Chromium’s PerfTestRunner and benchmarks the performance impact of CSS. This PerfTestRunner is what Blink (= Chromium’s underlying rendering engine) uses for its internal performance tests.

The runner includes a measureRunsPerSecond method which is used for the tests. The higher the number of runs per second, the better.

The created benchmarks for @property specifically measure how fast Blink can handle a Style Invalidation and the subsequent Recalculate Style task. This was tested with both registered and unregistered custom properties, as well as regular properties.

Read “Benchmarking the performance of CSS @property” on web.dev →
Check out “css-selector-benchmark” on GitHub →

Last week I joined my colleagues Adam and Una on The CSS Podcast. I was brought on to talk about View Transitions, a feature I’m doing the DevRel work for at Google.

In this episode Una and Adam bring on an esteemed guest Bramus, who brings us deep knowledge on View Transitions. These are easy to get started with but difficult to master, but not with Bramus here to teach us. He’ll be covering introductory to advanced API features and a big bag of examples and demos.

You can watch the episode on YouTube, which I have embedded below:

You can also listen to it using your favorite podcasting app.

I have a new article up on developer.chrome.com:

An often requested CSS feature is the ability to animate to height: auto. A slight variation of that request is to transition the width property instead of the height, or to transition to any of the other intrinsic sizes represented by keywords like min-content, max-content, and fit-content.

As of Chrome 129 you can now use the interpolate-size property or the calc-size() function to enable smooth transitions and animations from lengths to intrinsic sizing keywords and back.

The gist is to add the following snippet to your stylesheet to opt-in to interpolating from <length-percentage>s to any of the supported <intrinsic-size-keyword>s or vice versa.

:root {
    interpolate-size: allow-keywords;
}

The alternative is to use the calc-size() approach (which nowadays requires two arguments btw), but in most cases interpolate-size: allow-keywords; will do just fine.

Find all the details and a bunch of demos in the article Animate to height: auto; (and other intrinsic sizing keywords) in CSS.

~

I love this demo by Temani Afif. As you drag the thumb of the range input, the tooltip updates. It’s a combination of @property, counters, anchoring, and scroll-driven animations.

See the Pen CSS-only Custom range slider by Temani Afif (@t_afif) on CodePen.

Cranking it up a noth, Temani also incorporated my approach to a CSS-only scroll velocity detection to make the tooltip jiggle as you drag the thumb across.

See the Pen CSS-only Custom range slider with motion by Temani Afif (@t_afif)on CodePen.

Love it! 😍

For this year’s Google I/O, I recorded the session “Multi-page application View Transitions are here”.

Last year, we debuted Same-Document View Transitions for use in your Single-Page Applications (SPAs), and now we’re taking it to the next level. Get ready for enhanced control over View Transitions to more easily create immersive user experiences. We are also giving you Cross-Document View Transitions which allow you to create seamless navigations in your Multi-Page Applications (MPAs).

In the talk, I cover two main topics:

1. Cross-Document View Transitions for Multi-Page Applications
2. View Transitions Improvements (view-transition-class and View Transition Types)

You can find the video embedded at the top of this post. If you’re more into reading, check out the announcement blog post. The documentation up on developer.chrome.com also got an overhaul.

Watch “Multi-page application View Transitions are here” on YouTube →
Read the announcement blog post →
Read the updated documentation (SPA + MPA) →

I’m proud to announce the release of “Unleash the Power of Scroll-Driven Animations”, a 10-part video course I created that teaches you all there is to learn all about scroll-driven animations with CSS or JavaScript.

With scroll-driven animations you can take an existing CSS or WAAPI animation and animate it on scroll. Because of that, scroll-driven animations inherit all of the benefits these APIs bring. This includes hardware accelerated scroll-driven animations that are not subject to jank when the main thread gets blocked.

📝 Read the announcement post →
📺 Watch the videos on YouTube →
🧑‍🔬 Check out the demos and tools →
🧑‍💻 Get the debugger extension →

I’ve written about light-dark() before here on bram.us, and last month I also wrote an article for web.dev about it.

The article takes a bit of a different approach, so it’s still worth a read even when you’ve seen my previous one before.

System colors have the ability to react to the current used color-scheme value. The light-dark() function exposes the same capability to authors.

I’m especially fond of this demo that I built. The page responds to your Operating System’s light/dark setting but also allows overriding light/dark mode by changing the value of the color-scheme to only light or only dark.

See the Pen
Color switching with light-dark() and color-scheme by web.dev (@web-dot-dev)
on CodePen.

CSS color-scheme-dependent colors with light-dark() →

If you ever struggled with ::backdrop not having access to custom properties, here’s some good news:

As of Chrome 122 – and also in Firefox 120 and soon Safari 17.4 – ::backdrop is a tree-abiding pseudo-element, meaning that it inherits any inheritable properties from its originating element.

Go check out the article I wrote for developer.chrome.com for all details + a demo.

Changes to CSS ::backdrop inheritance →

Nuanced piece by Tero Piirainen on where Tailwind took a good practice, twisted it around, and took it for a run.

Use it or don’t, love it or hate it, but this last sentence of the article hits close to home:

Learn to write clean HTML and CSS and stay relevant for years to come.

Frameworks come and go. The foundations are here to stay.

Tailwind marketing and misinformation engine →