~

Mid May, at this year’s Google I/O, Una and I gave a talk “What’s new in Web UI” live at Shoreline in the Chrome tent. The talk was recorded and you can watch it here:

Take a fast-paced tour of the latest UI features landing in browsers today, with a lens on making beautiful web experiences. From updates to interactive capabilities like scroll-triggered animations and scoped view transitions, to the latest in UI components, learn how to build performant interfaces using native CSS and HTML primitives. Discover how to ship better user experiences with less code.

You can find all the demos in this handy CodePen collection. On Chrome for Developers, we have an accompanying blog post that covers the contents of this talk.

Watch “What’s new in Web UI” on YouTube →
Read “What’s new in Web UI” on Chrome for Developers →

~

Table of Contents

• The Talk
• Slides
• Recording/Video
• Thanks!

~

# The Talk

This talk dived deeply into the more experimental stuff of View Transitions.

Ever wondered what happens when you push the View Transition API beyond its documented limits? This talk throws caution to the wind and explores the wild side of View Transitions, cranking them up to 11. We’ll combine them with Scroll-Driven Animations, trigger them automatically with MutationObserver, and even resurrect classic Internet Explorer’s Page Transitions using this modern API. Prepare for unconventional use cases, unexpected results, and a healthy dose of experimentation as we venture beyond the spec. If you’re a web developer who loves to tinker and push boundaries, this is the talk for you.

The talk was a reprise of my rendition at Beyond Tellerrand just a few weeks earlier, but with shuffled and altered content, after Dave Letorey and Remy Sharp gave me very valuable feedback while at BT. Thanks, lads!

~

# Slides

The slides of my talk are up on slidr.io are embedded below:

My deck is riddled with videos and animations, but because this is a PDF export these are not included in the embed above.

~

# Recording/Video

The talk was recorded and you can watch the video on YouTube. It is also embedded below:

~

# Thanks!

I’ve heard many great things about All Day Hey! over the years, so it was on my wishlist to ever speak there. Back in November 2025 I sent a cold DM to organizer Josh Nesbitt, offering to speak at his event. I knew I was extremely late with my request, and after some back and forth, I was absolutely delighted when Josh confirmed my slot.

It was almost a very close call, though. Just a few days before the event, I ate something bad and spent the better part of the night hugging my toilet. Thankfully, it was just food poisoning rather than a full-blown stomach bug, so I bounced back in time to make it to the event fully energized.

The day before the conference, we were treated an incredible speaker dinner. Honestly, the food was soooo good!

One quick late night rehearsal run (with some last minute tweaks, of course) I was ready for the conference day itself the day after. And as expected, the atmosphere was fantastic. It was an incredibly friendly crowd, and it felt good to run into so many familiar faces again. Catching up and/or talking tech with Jake, Ana, Ryan, Dave, Remy, Oliver, Barry, Safari, Cassie, Alistair, Phil, James, Keith, Luke, Josh, … really made the day special.

One of the absolute highlights for me was an unexpected shout-out from Jake Archibald on Bluesky. He praised the job I’ve been doing with View Transitions since taking over the work after he left Google. Coming from him, that really meant the world to me.

My only sadness about leaving Chrome at the time, was stopping working on view transitions, but @bram.us took that on, and is doing it _so well_.

[image or embed]

— Jake Archibald (@jakearchibald.com) May 7, 2026 at 11:38 AM

~

~

Table of Contents

• The Talk
• Slides
• Recording/Video
• Thanks!

~

# The Talk

I initially planned on giving the talk “Supercharge Web UX with View Transitions” at Beyond Tellerrand as the crowd is a mix of technical and non-techical people. However, after chatting with Matthias an Quinten, I decided to switch to “Cranking View Transtions up to 11” as it lines up better with the concept of Beyond Tellerrand

Ever wondered what happens when you push the View Transition API beyond its documented limits? This talk throws caution to the wind and explores the wild side of View Transitions, cranking them up to 11. We’ll combine them with Scroll-Driven Animations, trigger them automatically with MutationObserver, and even resurrect classic Internet Explorer’s Page Transitions using this modern API. Prepare for unconventional use cases, unexpected results, and a healthy dose of experimentation as we venture beyond the spec. If you’re a web developer who loves to tinker and push boundaries, this is the talk for you.

~

# Slides

The slides of my talk are up on slidr.io are embedded below:

Unfortunately these exported slides don’t contain any of the slide transitions that supported the story I was bringing. Also missing are any recordings of the included demos (they’re just screenshots in the export), but you can click the links to check them out yourself.

~

# Recording/Video

The talk was recorded but the recording has not been released yet. Instead, you can watch the recording from my rendition at All Day Hey! which I did just two weeks later.

~

# Thanks!

Beyond Tellerrand is one of those conferences that I have been following from the sidelines for quite a while, but for some reason, I never actually made it to the event—there was always some scheduling conflict that got in the way. But now, after all those years, I finally made it. It was great to see firsthand that organizer Marc Thiele is exactly the kind and warm person he always appeared to be from afar.

Everything at BT is so well thought of (like, they had custom made opening titles and posters, created by Brendan Dawes), but what truly sets the event apart is its chill, relaxed, and incredibly welcoming atmosphere.

Marc also did an excellent job at curating the sessions. It was an absolute honor to share the stage with Oliver Reichtenstein, Niels Leenheer (lasers! doom!), James Victore, Annie Atkins (Wes Anderson is one of my favorite directors), Andre Michelle (OpenDAW!), James White, and Lauren Celenza — Your talks wildly inspired me and made a lasting impression.

(The fire alarm going off in the hotel at 5:30 also was quite memorable 😵)

To top it all off, the real value you take away from this conference are the connections. Extra shout-out to Brecht De Ruyte, Matthias Ott, Quentin, Remy Sharp, Dave Letorey, Nils Binder, Schepp, Marco, Charis, and Daniela as well — It was great catching up between and after sessions with all of you.

~

~

Early 2000s’ Pixel Perfection

If you, like me, were building websites back in the early 2000s, you’ll undoubtedly remember the absolute headache that was cross-browser compatibility.

What didn’t help back then in this era of Internet Explorer, Netscape, and Firefox was the stubborn, widespread belief that websites needed to look exactly the same in every single browser. Pixel perfection was the (flawed) holy grail.

Thankfully, the web community eventually came to its senses by embracing Progressive Enhancement. The single-purpose website dowebsitesneedtolookexactlythesameineverybrowser.com that just displayed a giant, resounding “no” on the screen, was a great way to spread the word.

The site was featured in quite a lot of conference talks, such as Jeremy Keith’s talk from border:none 2013 (at the 39:18 mark):

But there’s a fundamental thing, a fundamental philosophical approach that you have to approach your work with, if you’re going to use progressive enhancement. And it’s simply answering the question, do websites need to look exactly the same in every browser?

A very simple question. And you can find out the answer to this question by going to the website, dowebsitesneedtolookexactlythesameineverybrowser.com, where you will see the answer written out there on the screen: No.

However, the answer will appear different, depending on the browser you’re using, because of CSS and JavaScript enhancements. It’s a self-describing definition of progressive enhancement done by Dan Cederholm.

But still, it took years to shed that misconception. And while we’ve now accepted that websites don’t need to look the same everywhere, we seem to be stuck on a new hurdle: the idea that websites need to function the same everywhere.

(Spoiler: No, they do not.)

~

A shifting paradigm

A lot has changed since those early days. Safari and Chrome came into existence and practically took over. The iPhone arrived and set the baseline for what a mobile device with a “breakthrough internet communicator” should be. Today, browsers run on just about everything: laptops, phones, tablets with styluses, tablets with keyboards, smartwatches, you name it.

Each of these devices comes with its own input methods and interaction paradigms. On a desktop, you typically scroll with a mouse wheel. If you can’t use a mouse, you use the keyboard. On touch devices, you swipe with one finger and pinch-zoom with two fingers. And on spatial computing devices like the Vision Pro, you can scroll using your hands or just using your eyes.

~

Embracing input-specific features

One of the things I like about a lot of modern web apps out there is that they have added keyboard shortcuts to their UI. Sites like YouTube, GitHub, Gmail, and Feedly all offer them. The de facto standard now is to press the ? key to bring up a dialog detailing all available keyboard shortcuts.

These shortcuts are an extra way to reaching a specific goal. On YouTube for example, you can hit the f key on your keyboard to fullscreen the currently playing video. Because this extra type of activation is strictly limited to the keyboard input method, it is unique to that input method. When there is no keyboard available, you can’t use it, and you still have to locate and click the fullscreen icon in the UI.

I like to use these shortcuts as the perfect example to show that it is perfectly fine for sites to offer different, alternative, functionality based on what the platform and input method can offer:

• Got touch? Great, you can now swipe and pinch-zoom on things.
• Got a keyboard? Great, you can focus elements by tabbing into them.
• Got a pointer device? Great, things can now happen on hover.
• Using a keyboard? Great, you can use handy shortcuts.

A practical example here is a modal dialog that is getting shown: depending on which platform and input mechanism combo you are using, you can close it by flinging it away, hitting the ESC key, doing a back swipe, tapping the backdrop, or by activating the close button.

~

The impact on Web Platform features

These aren’t just abstract observations. The friction between platform-specific capabilities and the desire for universal functionality is actively bottlenecking very hot topics currently being developed for the web platform.

~

Interest Invokers

For the past 1.5 years, there has been a lot of discussion on how interest invokers should work on touch devices. On touch devices, the de facto standard to express "interest" in an element is to long-press it. But browsers on touch devices already use that long press to reveal the system context menu (*). This clash pushed the Open UI folks to explore more options. Chrome is currently prototyping the ::interest-button pseudo-element option behind a feature flag but it’s already becoming clear that, although well-intended, enabling it by default is doing more harm than good.

(* Unless you do the proprietary -webkit-touch-callout: none on iOS)

~

Overscroll Actions / Areas

Overscroll Actions / Areas is another feature currently being explored at Open UI. A major sticking point is discoverability on desktop devices. Some folks are arguing that there must be a visible button in the UI to reveal these overscroll areas on desktop. My take? There shouldn’t be. People naturally try out swipe/scroll gestures on trackpads nowadays, and just like keyboard shortcuts, this is simply an extra means of reaching a goal, not the only one. Your UIs should already be accessible without Overscroll Areas — Check out the issue for more details on this (the email interface example).

~

Document Picture-in-Picture

Picture-in-Picture (PiP) is a well-established paradigm for video. The newer Document Picture-in-Picture API extends this functionality, allowing you to pop any HTML content into a floating window. It’s brilliant for things like tabbing away from a Google Meet call and keeping the call controls and participant videos visible. Yet, WebKit formally opposed the API, stating it is a paradigm that doesn’t map well to all platforms.

They specifically called out that on iOS and iPadOS, system-level picture-in-picture is specifically designed for video content … which seems like a “you-problem” IMHO.

(For completeness: they also mentioned being concerned about the user experience implications of giving websites the ability to create always-on-top windows but in the same spirit I also have my concerns about the color property because developers can create light-text-on-a-light-background experiences that also implicates UX …)

~

Moving Forward

The main theme across all these discussions, debates, and oppositions is a lingering belief that web features must work the exact same way on all platforms.

If we as a community (and as platform engineers) started accepting that websites do not need to function exactly the same on every platform, these feature discussions could have been finished a long time ago (or would at least go down easier), allowing web developers to just build better, progressively enhanced experiences for their users.

Singling out the Interest Invokers use-case: if the long press is a no-go, and the always-on ::interest-button is pushing folks to force removing them (as the initial replies suggest), then perhaps the answer is to make them opt-in or, even further, not having them at all? Like, I wouldn’t really mind not seeing an info card on GitHub or Wikipedia when using touch as the input mechanism, because the info show in those cards is available on the next page anyway … and perhaps that’s OK?

~

~

view-transition-name: attr(…);

To recap, the technique Kevin showed is this:

<style>
  .card {
    view-transition-name: attr(data-id type(<custom-ident>), none);
    view-transition-class: card;
  }
</style>

It reads the data-id attribute’s value and casts it to a <custom-ident> for use as the view-transition-name value.

You can see Kevin apply it live here. When applied, all cards will get a view-transition-name and get snapshotted — and therefore also move — individually as part of the View Transition.

~

view-transition-name: match-element;

The thing Cyd mentioned is match-element, which automatically gives an element a view-transition-name value based on the element’s identity. In Kevin’s demo this would totally work, and the demo would work just as with the attr() code.

<style>
  .card {
    view-transition-name: match-element;
    view-transition-class: card;
  }
</style>

So, what’s the fuss about then?

~

match-element works … until it doesn’t

The thing with match-element is that it uses element identity to assign automagic values. This element identity is not to be confused with the id attribute — they are two different things.

Think of this identity as an internal number that the browser assigns to created elements. Every time an element is created, the internal counter increments. So if you were to destroy an element and then recreate it including its id, you’d end up with an element that that has a different identity, even though it has the same id.

The side-effect of match-element using element identity, is that are two scenarios when you should not be using match-element at all:

1. When you build an MPA (aka: a website), match-element doesn’t work at all because nodes in different documents are never the same; they all have a different identity, so match-element can never match them.
2. If you need to style a specific element from the whole set, then you need the unique name to use in your ::view-transition-*() selectors, which match-element doesn’t give you.

So, there you have it 🙂

~

~

~

~

The view-transitions-toolkit

view-transitions-toolkit is a collection of small, focused helper functions for use with View Transitions. They fill in some of the gaps to making advanced patterns much easier to implement.

• Feature Detection: Get information about whether certain View Transitions sub-features are supported.
• Shim Support: Shim support for document.activeViewTransition.
• Animations: Utilities for extracting, measuring, and optimizing animations.
• Transition Playback Control: Pause, Resume, or Scrub the playback of a View Transition.
• Automatic Page Navigation Types: Automatically inject View Transition Types based on navigation origin/destination.

The goal of the project is to provide these utilities so you don’t have to reinvent the wheel every time you want to do something slightly advanced with View Transitions.

~

Getting Started

Using the toolkit is incredibly simple. First, install it from npm:

npm i view-transitions-toolkit

Then, you can import the modules you need and use their functions. Optimizing the keyframes of a View Transition group for example is a simple one-liner:

import { optimizeGroupAnimations, OPTIMIZATION_STRATEGY } from "view-transitions-toolkit/animations";

const t = document.startViewTransition(() => { … });
await t.ready;

// Optimize all Group Animations using the default SCALE strategy
optimizeGroupAnimations(t, "*");

// Optimize only the `::view-transition-group(box-flip)` animation using the SLIDE strategy
optimizeGroupAnimations(t, "box-flip", OPTIMIZATION_STRATEGY.SLIDE);

I won’t go into details here, as all features are documented in the docs folder of the repo.

~

Demos

The project also comes with a public website that not only gives you the basic info, but also comes with a bunch of demos: https://chrome.dev/view-transitions-toolkit/.

The source of the demos is included in the repository as well.

~

Go check it out

• view-transitions-toolkit demos (Chrome.dev) →
• view-transitions-toolkit source (GitHub) →
• view-transitions-toolkit on NPM →

~

Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~

~

# The Situation

To understand the impact, let’s quickly review the standard setup for a responsive table. You start with a wide HTML <table> full of data. To prevent this wide table from breaking your page layout on small screen devices, you typically wrap it in a container with overflow-x: auto.

<div class="table-wrapper" style="overflow-x: auto;">
  <table>
    …
  </table>
</div>

Because you want the column headers (the <thead>) to stay visible when scrolling down the document, you apply position: sticky; top: 0; to them. Simultaneously, you want your first column to stay visible when scrolling sideways through the data, so you apply position: sticky; left: 0; there.

.table-wrapper {
  overflow-x: auto;
}

.table-wrapper thead {
  position: sticky;
  top: 0;
}

.table-wrapper td:first-child {
  position: sticky;
  left: 0;
}

However, this doesn’t work as expected. While the first column will stick to the left edge of the table wrapper when scrolling horizontally, the headers will scroll out of view along with the rest of the page.

This is because the .table-wrapper becomes the sticky reference for both axes. Because the wrapper only scrolls horizontally, the vertical sticking becomes completely ineffective. Your top: 0 headers would just happily scroll out of view along with the rest of the page 😭

To get around this, you had to rely on lots of JavaScript to synchronize the scroll position, or rely on duplicated headers.

~

# The Change

Thanks to a recent change in the overflow specification that allows containers to be a scroller for only a single axis, position: sticky can now track two different scrollers — one per axis — for the stickiness.

This means that for our wide data table:

• The first column can be sticky on the horizontal axis against the table wrapper.
• The headers can be sticky on the vertical axis against a completely different scroller — such as the document itself!

No more duplicating headers. No more scroll-syncing JavaScript. Just plain CSS doing exactly what you’d expect it to do.

This change is available for testing in Chrome 148 with the Experimental Web Platform Features flag enabled.

~

# See it in action

You can see this new behavior in action in this CodePen demo:

See the Pen
CSS `position: sticky` for Single Axis Scroll Containers by Bramus (@bramus)
on CodePen.

If you view the demo in a supported browser, the first column will stick to the left edge of the table wrapper when scrolling horizontally, and the top headers will stick to the top of the viewport when scrolling vertically.

~

# An Important Detail: Watch your overflow

If you look closely at the CSS in the demo, you might notice a very specific detail in how the .table-wrapper is styled.

.table-wrapper {
  overflow: auto clip;
}

To make the wrapper scroll horizontally, you might instinctively reach for overflow-x: scroll (or auto). However, doing so will actually break the vertical stickiness we just achieved!

Why? Because in CSS, if you set overflow-x to scroll or auto, the browser automatically computes overflow-y to auto as well (assuming its value was visible). This turns the wrapper into a scroll container on the vertical axis too, which means it once again traps our headers and becomes their sticky reference.

To fix this, we need to explicitly tell the browser not to create a scroll container on the block axis. We do this by using the clip keyword:

.table-wrapper {
  /* ❌ This makes overflow-y compute to auto, breaking vertical stickiness */
  /* overflow-x: auto; */

  /* ✅ This creates a scroller on the inline axis, but clips the block axis */
  overflow: auto clip; 
}

By setting overflow-y to clip (via the overflow shorthand), the wrapper does not become a scrollport on the vertical axis. The headers are therefore free to track the document viewport instead.

~

# Browser Support

At the time of writing, this feature is only supported in Chrome 148 as an experimental feature.

Chromium (Blink)

👨‍🔬 Available in Chromium 148.0.7742.0 with the experimental web platform features flag flipped on.

Firefox (Gecko)

❌ No support

Subscribe to Bug #2023702 for updates.

Safari (WebKit)

❌ No support

~

# Feature Detection

Because older browsers still use the inner container as the sticky reference for both axes, you might want to feature-detect this new behavior to provide JS-based fallbacks or conditionally load specific styles.

While we can’t easily detect this layout behavior directly with an @supports query in CSS yet — I have an open issue at the CSSWG for this — you can feature detect this using JavaScript. The CodePen demo linked above includes a script that does exactly this.

It handles the detection by evaluating how the browser resolves the sticky positioning offsets within a scrolling wrapper. Feel free to peek at the JS tab in the Pen to grab the snippet for your own projects.

@supports named-feature(single-axis-scroll-container) {
  /* Single Axis Scroll Containers are supported */
}

~

# Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 Bluesky
• 🦣 Mastodon

~

Ever wondered what happens when you push the View Transition API beyond its documented limits? This talk throws caution to the wind and explores the wild side of View Transitions, cranking them up to 11. We’ll combine them with Scroll-Driven Animations, trigger them automatically with MutationObserver, and even resurrect classic Internet Explorer’s Page Transitions using this modern API. Prepare for unconventional use cases, unexpected results, and a healthy dose of experimentation as we venture beyond the spec. If you’re a web developer who loves to tinker and push boundaries, this is the talk for you.

I also gave this talk at Beyond Tellerrand 2026 about a month later. You can find the slides of the talk in the Beyond Tellerrand 2026 post.

~

~

# The Missing Piece

As a recap, in CSS, you have to write something like this if you want to set background-images for light and dark mode:

:root {
  --bg-image: url(light-pattern.png);
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg-image: url(dark-pattern.png);
  }
}

.element {
  background-image: var(--bg-image);
}

This code has downsides: The necessary parts can be scattered all over the place and it only checks the global color-scheme preference without respecting local color-scheme overrides done with the color-scheme CSS property.

Thanks CSS light-dark() we can keep our code closely together, and can respond to the local used color-scheme value. In it’s updated form – in which light-dark() now also supports <image> values – that whole block can be collapsed into a single rule, and we can make it respect local color-scheme overrides:

.element {
  color-scheme: dark;
  background-image: light-dark(url(light-pattern.png), url(dark-pattern.png));
}

Sweet!

~

# Browser Support

It’s early days, but the engines are already moving:

Chromium (Blink)

✅ Supported in Chrome 150. Chrome 150 is expected to go stable on Jun 17, 2026

Firefox (Gecko)

✅ Supported in Firefox 150

Safari (WebKit)

❌ No support

Subscribe to WebKit Bug #309689 for updates.

~

# Feature Detection

If you want to start experimenting today while providing a fallback, you can use @supports. To detect support for images specifically, you can test it using linear-gradient() (which is treated as an <image> in CSS) or — another new addition — the keyword none:

@supports (background-image: light-dark(none, none)) {
  /* Modern image-switching logic here */
}

You can see the code in action this CodePen:

See the Pen CSS light-dark(<image>, <image>) Support test by Bramus (@bramus) on CodePen.

~

# What about non-<color> and non-<image> values?

Supporting non-<color> and non-<image> values still is an unanswered question (that probably won’t get solved). As explained in my original coverage, CSS can’t just simply accept light-dark() anywhere because the parser needs to know the value type of what it is parsing ahead of time.

Internally, light-dark() is about to be defined as having two internal variants – one that accepts <color>s and one that accepts <image>s:

light-dark() =  <light-dark-color> | <light-dark-image>
<light-dark-color> = light-dark(<color>, <color>)
<light-dark-image> = light-dark(<image>, <image>)

Each variant has limitations on where it can be used: the version that does colors is only accepted where <color>s are allowed, and the version that does images is only accepted where <image>s are allowed.

<color> = <color-base> | currentColor | <system-color> | 
          <contrast-color()> | <device-cmyk()> | <light-dark-color>

<image> = <url> | <image()> | <image-set()> | <cross-fade()> | 
          <element()> | <gradient> | <light-dark-image>

If more types of values needed to be supported, that would required many more internal variants.

This split into two variants allows the CSS parser to discard invalid declarations at parse time. That, in turn, explains why you can’t mix the types in the arguments. Say CSS were to accept a mix of <color> and <image>, then you would be able declare something like background: red light-dark(blue, url(dark.png));. With a dark color-scheme that declaration would end up being OK, but in a light color-scheme you’d end up with background: red blue which is invalid.

Looking ahead: @function + color-scheme() to the rescue!

In the future there will be an way to have non-<color> and non-<image> color-scheme-dependent values in the future: using a CSS Custom Function and color-scheme(). Go check out my previous post on implementing a custom --light-dark() function that works with any type of value for the details. It’s just 3 lines of code, which I’ve included here as well:

@function --light-dark(--l, --d) {
  result: if(color-scheme(dark): var(--d); else: var(--l));
}

To feature detect support for @function, check out @supports at-rule(). There currently is no easy way to detect support for color-scheme(), unless you want to jump through some hoops.

~

# Spread the word

Feel free to reshare one of the following posts on social media to help spread the word:

• 🦋 BlueSky
• 🦣 Mastodon
• 💼 LinkedIn

~

~

The solution (Updated)

The core idea remains the same as back in 2022: use the at-rule() function within an @supports query to check if a user agent recognizes a specific at-rule.

@supports at-rule(@starting-style) {
  /* CSS for browsers that support @starting-style here … */
}

The function simply checks if the browser would accept an at-rule in any context. This is super useful for detecting entire new features like @starting-style.

You can also use at-rule() in the supports-condition when doing an @import:

/* This CSS only gets imported when @view-transition is supported (and the browser supports at-rule() as well) */
@import "view-transitions.css" supports(at-rule(@view-transition));

~

No descriptors, preludes, or full blocks!

In my original coverage of at-rule(), I mentioned an extension to the feature that would theoretically allow you to detect support for specific descriptors (e.g. at-rule(@counter-style; system: fixed)) or even pass in a full at-rule block.

This extension — along with checking for at-rule preludes (= the part between the at-rule and the opening {) — has been dropped. The following examples will all fail, as those are not supported:

/* ❌ Passing in descriptors is not supported */
@supports at-rule(@counter-style; system: fixed) { … }

/* ❌ Passing in full at-rules is not supported */
@supports at-rule(@counter-style { system: fixed }) { … }

/* ❌ Passing in preludes of at-rules is not supported */
@supports at-rule(@container style(…)) { … }

Because preludes are not allowed in at-rule(), it cannot be used to detect non-size @container queries support (e.g. style queries, anchored queries, etc.). To detect those, fall back to sniffing out support for the various values of container-type — a technique you can already use today in all browsers:

@supports (container-type: anchored) {
  /* CSS for browsers that support anchored queries here … */
}

To feature detect style queries — which has no tell-tale property/value pair — you can use this workaround I previously documented:

html {
  --sentinel: 1;
}

@container style(--sentinel: 1) {
  /* Style Queries Supported! */
}

~

Browser Support

@supports at-rule(@keyword) is available in Chromium 148. The initial implementation was done by Google and Kevin from Microsoft pushed it over the finish line while also navigation the paperwork with the CSS Working Group.

Chromium (Blink)

✅ Supported in Chromium 148 and up.

Firefox (Gecko)

❌ No support

Follow Issue #1751188 to stay up-to-date and signal interest.

Safari (WebKit)

❌ No support

Subscribe to Issue #235400 to stay up-to-date and signal interest.

~

Feature Detection

You can feature detect support for at-rule() by checking for support for @supports itself.

@supports at-rule(@supports) {
  /* ✅ The browser supports `@supports at-rule(…)` */
}

You can see it in action in the following demo:

See the Pen
CSS @supports at-rule() test by Bramus (@bramus)
on CodePen.

~