~

~

The Problem: Targeting Multiple Prefixed Classes

When coming up with classnames for use in the class attribute, a common practice is to use a prefix to retain some grouping or hierarchy. You might be familiar with classes like .btn-primary, .btn-secondary, .btn-danger, and so on.

To apply a base style to all of these buttons today, you typically have to list them all out, or introduce a separate .btn base class:

/* Adding a base class */
.btn {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

/* Or listing everything... yuck! */
.btn-primary,
.btn-secondary,
.btn-danger {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

Some of you even resort to substring-matching attribute selectors, but those can be notoriously brittle and ugly when dealing with multiple classes on a single element:

/* Works, but can be error-prone with whitespace */
[class^="btn-"],
[class*=" btn-"] {
  padding: 0.5rem 1rem;
}

~

The Solution: The Class Prefix Selector

Just two weeks ago, at the CSS Working Group F2F meeting in Berlin (August 2026), we resolved to add a dedicated Class Prefix Selector to the CSS Selectors Level 5 specification. The idea was originally pitched by Lea Verou back in 2024 (w3c/csswg-drafts/#10001).

The syntax is incredibly straightforward:

.btn-* {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

That’s it! The -* part at the end makes the selector a Class Prefix Selector and will try to match any class that begins with that hyphen-separated prefix.

It’s a huge win for utility classes and design systems, allowing you to easily target groups of related elements without having to bloat your HTML payload or write fragile attribute selectors.

~

What about the empty string?

An interesting question that popped up during the discussions is whether .foo-* should match the empty string (w3c/csswg-drafts/#14291), meaning: should .foo-* also match an element that merely has the .foo- class?

While the exact default behavior is still being ironed out, currently the selector is specified to only match classes that start with the prefix and that have at least one character beyond the prefix (and the first such character beyond the prefix is not also a hyphen)

So no, class="foo-" would NOT be matched by .foo-*, which I think is fine. That same selector also would not match class="foo--", which is also probably fine.

~

What about non-dashes?

The Class Prefix Selector is currently limited to hyphen-separated prefixes, at least at first. Other separators, like _, might be added as possibilities in the future as we receive request from authors like yourself about what would be needed.

One thing that is already quite clear right now, is that there must at least be some separator. Arbitrary prefixes (like .foo*) are not going to be allowed for at least two reasons:

1. You could accidentally overselect: .foo* would also match .footer
2. Selector Performance: Browsers typically create buckets for class selectors for quick selector matching. Adding arbitrary wildcards defeat that optimization.

Similarly, wildcards in the middle of a selector (such as .card-*-primary) are also not going to be allowed.

# Browser Support

Since this was literally just resolved at the CSSWG F2F in Berlin two weeks ago, browser support is currently non-existent. To follow along with the progress – if any – you can follow these browser issues:

Chromium (Blink)

❌ No Support

Subscribe to CrBug #543356377 to follow along.

Firefox (Gecko)

❌ No Support

There is no bug tracking this yet.

Safari (WebKit)

❌ No Support

There is no bug tracking this yet.

This feature is still in its early days and needs to be fleshed out further, so could be that it takes a few more years before you can use it in production …

# Feature Detection

You can feature detect support with a regular @supports rule:

@supports selector(.foo-*) {
  /* Browser has support */
}

The following CodePen uses this and will light green when you browser supports it:

See the Pen
CSS Class Prefix Selector Support test by Bramus (@bramus)
on CodePen.

Spread the word

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

• 🦋 Bluesky
• 🦣 Mastodon

~

~

A raised eyebrow

The whole thing started about two weeks ago. While browsing through Modern Web Guidance’s guides, I noticed that the dark mode guide advises authors to use a two-state control when offering a Dark Mode toggle to their users.

Use a two-state control

This had me raise my eyebrow, as I strongly believe that these type of controls should be a tri-state control.

Here’s what I wrote back in 2020 when I recreated a Dark Mode toggle by Josh W. Comeau using Vanilla JavaScript:

🤔 One thing that I personally find missing from Joshua’s implementation is a way to reset the override. To not diverge too much from his implementation I’ve added the reset option via a separate link. What ideally could be done is to use radio buttons (instead of a checkbox) or a dropdown to change between auto, light, and dark.

So, I went on and quickly filed GoogleChrome/modern-web-guidance-src#1182 to get the MWG guide fixed. I didn’t add too much reasoning, as I (wrongly) assumed this was a well lit path. A bit later, guide author Lea Verou replied, pointing to the UX motivation part of the guide, which reads:

DON’T expose all three states (system, light, dark). While the rationale is plausible — “Follow system (currently dark)” is a distinct user intent from “Always dark” — it provides suboptimal UX:

• Users cannot meaningfully express intent for problems they don’t currently have. A manual toggle is a temporary comfort adjustment (“it’s too bright right now”), not a long-term preference (“make sure this never changes”).
• Two of the three options always produce the same visual result, violating the principle of feedback.

I’m not really convinced of that argumentation, because:

• A manual toggle is a temporary comfort adjustment
  → Why shouldn’t it be a long term thing? The chosen option is persisted after all …
• Two of the three options always produce the same visual result, violating the principle of feedback.
  → While the whole page might not change indeed, the selected option does change so there is local visual feedback.

Furthermore, solely focusing on the feedback part is ignoring other benefits of the tri-state control, including predictability and clarity — “Don’t Make Me Think”

~

The F2F, The Debate, and The Data

Coincidentally, the week after I filed the issue, the CSS Working Group Face-To-Face (F2F) took place in Berlin, where both Lea and I were present.

We spent some time trying to convince each other of our respective views, but quickly realized we couldn’t convince each other and also needed some numbers to back up our claims. Lacking some broader research about this topic, we both turned to social media to ask folks for their input.

I posted the following on Bsky and Mastodon:

QQ about Dark Mode Toggles on websites

How many options do you show to users?

• Three values: System, Light, or Dark
• Two values: Light, Dark (with one of them mapping to “System” behind the scenes).

Why the one or the other?

(I have an opinion about it, but I’m looking for external input)

Tallying up the results after about 24 hours, the answers were overwhelmingly in favor of a tri-state approach, with some of the replies even including some good arguments for their choice as well:

• Tri-state: 43
• Two-state: 7

(Note: 4 folks also answered that they don’t offer a control at all, and strictly follow the system preference — to me, that is the minimum you should do)

Simultaneously, Lea also ran a poll, asking if folks ever clicked on the override that matches their OS. While it’s good to try and get data, I found the question to be incomplete.

A bit later, Lea whipped up a case for a two-state control which she published on her blog: Dark mode toggles: two states are enough (you should read the whole thing).

However, after reading it, I still disagree. I firmly believe a tri-state control is the way to go.

~

The Problem with Two-State Controls

In short, I don’t believe that being able to force a site into a specific mode should be dependent on the time of the day.

The two-state approach highlighted in Lea’s post urges you to either store system or “the computed opposite of system” (i.e. light or dark — whichever is the opposite of the OS is) when using the control. If you carefully think about this, you’ll quickly realize that this runs into a very specific UX problem when the user’s OS is set to auto-change from light to dark based on the time of the day.

Imagine this scenario:

1. The user’s OS is set to auto-switch Light/Dark based on the time of day.
2. They visit a website during the day, so they see the Light theme.
3. Using the site’s two-state control, they try out the Dark theme. They decide they don’t like it, so they revert it back to Light.
4. They visit the site again at night.

Because the two-state toggle maps one of its values back to “System” behind the scenes, the site is now dark, although they explicitly chose light the last time they interacted with the control. You may now expect an incoming bug report for the control not properly working …

~

Doing Two-State Right (with caveats)

Now, to be clear, I am not entirely against two-state controls. They can work, as long as they clearly communicate to the user what is actually going on.

If you really want to offer a two-state control, here are a couple of ways to do it:

1. Explicitly label the system state

Include a label like “auto” (or an equivalent icon) on the value that follows the OS. This still carries the problem that the user can’t fixate their current OS preference, but at least the behavior is clearly communicated.

I actually took this approach in my chrome-dark-mode-toggle POC extension, which adds a Dark Mode toggle button to Chrome. It has one icon to click which toggles between System and Computed Opposite of System. Crucially, there is a clear “Auto” label present on the control so you know when it’s deferring to the OS.

2. Write explicit values to storage

Opposite to Lea’s recommendation, write the actual values (an explicit light or dark, never system) to storage so that you can actually force both states persistently.

However, if you do this, you inevitably need to offer a “reset” option so users can go back to following the system … at which point you might as well just make the control a tri-state one.

~

The Sweet Spot?

Another approach I’ve seen recently is Vale’s take on things, which shows two controls while still offering three states.

By default, when the site is following the OS preference, neither of the options are highlighted. This implicitly acts as the “System” state. When a user explicitly clicks Light or Dark, the UI highlights the choice, representing the two extra states that write explicit values to storage. When clicking the chosen value again, you end up back with no option selected.

See the Pen
Light/Dark/System Theme Setting by Declan Chidlow (@OuterVale)
on CodePen.

I really like Declan’s approach. It’s clean, and doesn’t sacrifice functionality.

~

Clarity over Brevity

When building these types of control, I think that one of the main goals here should be to keep things predictable for users. Once a user has interacted with a control, they have mentally set it to the specific state they have chosen. Things then changing based on the time of day are an unexpected surprise.

Three explicit options (System, Light, Dark) for a Dark Mode Toggle (or Vale’s clever UI trick) don’t come with this type of unexpected surprise. As Erik Kroes perfectly put it in his reply on Mastodon:

“Tri-state” prioritizes clarity over brevity.

And when it comes to user interfaces, clarity is exactly what users want most 🙂

~

~

Scroll Axis Locking?

By default, a browser often “locks” a user’s scrolling gesture to a single axis when that gesture starts with significantly more movement in one axis than in the perpendicular axis.

For example, say a user drags their finger on the screen such that the element underneath the finger would be scrolled by 500px in the y-axis and 3px in the x-axis. Because the gesture is almost entirely vertical, the browser might interpret the user’s intent to be a perfectly vertical scroll. As such, the browser can ignore the 3px scroll delta and (possibly) all further x-axis deltas for the remainder of the gesture. In this case, the browser has “locked” the scroll to the y-axis — a technique also known as “railing”.

In many cases, this scroll-locking behavior improves the user’s experience by avoiding accidental scrolls along the other axis when the user’s intent was to scroll only one axis.

However, in cases where you wish an element to always be diagonally scrollable, this locking behavior forces the user to start their gesture at an angle that doesn’t trigger the locking, often not in alignment with the author’s intended user experience.

Thankfully, a recent change to CSS now offers control over this, namely the scroll-axis-lock property described in the CSS Overflow 5 specification.

💁‍♂️ Note that this axis-locking behavior totally depends on the browser and platform. Safari and Firefox on macOS for example are very strict at it, while Chrome on macOS tries to more closely reflect your scroll’s intent (but still applies some locking)

Compare these two screenshots of Safari and Chrome: Safari’s scroll axis-locking results in a more etch-a-sketch-like scroll when scrolling in the shape of a circle (or attempt thereof 😅).

As for touch-platforms: From what I can tell, Safari on iOS doesn’t scroll lock at all, whereas Chrome on Android does.

~

Control scroll axis-locking with scroll-axis-lock

The scroll-axis-lock property gives you control scroll axis-locking. The property accepts the following values:

• auto (default): The browser may lock the scroll to a single axis if it determines the gesture is predominantly 1-dimensional. The browser may allow you to break out of scroll axis lock as part of your current gesture, but the thresholds to do that are different per browser and platform.
• none: Disables the locking mechanism entirely. The scroll container will faithfully follow the user’s exact input, allowing for unrestricted diagonal panning.

.scroller {
  scroll-axis-lock: auto; /* Default */
  /* or */
  scroll-axis-lock: none;
}

In the following video, you can compare how both values behave. The recording show Chrome 153 on macOS, but with a different scroll-axis-lock value. The scroll is performed using a trackpad.

The difference also becomes very clear when doing scrolls that follow a circular motion:

~

Try it yourself

To feel the difference yourself (and to create the screenshots and videos above), I built a demo that samples your pointer’s X/Y input deltas and compares them against the actual scrollLeft and scrollTop output of the container.

If you try scrolling diagonally with scroll-axis-lock: auto, you’ll notice the status indicator flag can show a “Axis Locked” warning it detects that the browser is ignoring your perpendicular input. As mentioned before this totally depends on the browser and platform, so could be that you don’t see this warning at all.

If you set the toggle to scroll-axis-lock: none, and try again, scrolling straight is way more “jittery” and scrolling diagonally immediately pans in both directions simultaneously, exactly following your gesture.

~

# Browser Support

Support for scroll-axis-lock looks like this:

Chromium (Blink)

✅ Supported in Chromium 153

Firefox (Gecko)

❌ No Support

Safari (WebKit)

❌ No Support

~

Feature Detection

There is no real need to feature detect this, as you can safely use scroll-axis-lock today as a progressive enhancement. Since it doesn’t break anything when ignored, you can just declare it directly 🙂

If you really do need to feature detect it — perhaps to load some alternative code? — you can use an @supports rule in CSS or CSS.supports() in JS to check.

@supports (scroll-axis-lock: none) {
  /* Control over scroll-axis locking supported */
}

if (CSS.supports('scroll-axis-lock: none')) {
  /* Control over scroll-axis locking supported */
}

The following embed uses this feature detection to indicate whether your current browser supports scroll-axis-lock:

See the Pen
CSS scroll-axis-lock Support test by Bramus (@bramus)
on CodePen.

~

Spread the word

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

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~

TIL: MDN exposes up-to-date page view data through https://popularities.mdn.mozilla.net/current.csv.

To visualize the data, I had Google AI Studio generate me a visualizer, which I deployed to CodePen

The data source file is downloaded by the app itself and stored in IndexedDB, so this is a one-time static deploy (using CodePen 2.0). When your local data is considered old, you get a warning to re-download it.

Check out “MDN Traffic Browser” →

One of the things that we at Chrome have been thinking about for a while now is a way to do declarative route and navigation matching in CSS. Together with Noam Rosenthal and David Baron I’ve been working on this for the past few months.

After an initial introduction at the CSS Working Group back in January, and a quick feedback session with developers at CSS Day in June, we think we have something that is ready for further discussion.

At next week’s CSS Working Group F2F (face-to-face) meeting in Berlin, we’ll be presenting our current line of thinking. This post is a quick intro to the concepts we’ll be covering.

~

The Problem: Knowing where you’re going

If you’ve played around with View Transitions, especially for Multi-Page Apps (MPAs), you’ve probably hit a familiar wall. Very often, you want to style a page differently based on where you are coming from and where you are going to.

Imagine a simple flow:

• When navigating from the index page to the about page, you want the whole site to slide to the left.
• When navigating back from the about page to the index page, you want it to slide to the right.
• When clicking a thumbnail in a list to go to a detail page, you want that specific clicked thumbnail to transition into the hero image.

Right now, doing this requires JavaScript to intercept the navigation, figure out the URLs using pageswap and pagereveal, find the NavigateEvent.sourceElement, and dynamically set the View Transition Types based on those values.

To see it in action, check out this this demo that uses the components mentioned above.

It works, but the script required to do it right grows over time and can become quite complicated. We wanted to see if styling the navigation experience can be done declaratively instead, in CSS.

~

Say Hello to Route and Navigation Matching 👋

The CSS Route and Navigation Matching Specification (css-navigation-1) introduces a few new key components to CSS that allow you to style the navigation and links declaratively.

“CSS conditioned on the status of navigating between particular URLs.”

Here is a quick (and abbreviated) overview of what we are proposing:

~

1. Define Routes with @route

Instead of constantly typing out URL strings, you can define named routes using the url-pattern() function.

@route --home { pathname: url-pattern('/'); }
@route --about { pathname: url-pattern('/about'); }
@route --detail { pathname: url-pattern('/detail/:id'); }

Pattern matching is done using the syntax from the popular path-to-regexp library, which is also used by JavaScript’s URLPattern.

(For completeness: You can also use the protocol, hostname, port, pathname, search, and hash descriptors to define a named route.)

~

2. Query the navigation with @navigation

This is where the magic happens. You can query the current, ongoing, navigation state using the @navigation at-rule, checking the from and to endpoints.

/* Going from home to about? Slide left! */
@navigation (from: --home) and (to: --about) {
  @view-transition {
    navigation: auto;
    types: slide-all-to-left;
  }
}

/* Going back from about to home? Slide right! */
@navigation (from: --about) and (to: --home) {
  @view-transition {
    navigation: auto;
    types: slide-all-to-right;
  }
}

You can query against a named route (defined with @route) or a direct url-pattern().

(For completeness: We are also introducing between and at keywords for the “navigation relation”.)

~

3. Select the element that triggered the navigation with :nav-source

The :nav-source pseudo-class selector allows you to target the exact element that initiated the outgoing navigation. This is modeled after NavigateEvent.sourceElement.

For example, If you want to apply a view-transition-name only to the specific image that was clicked, you can do this:

@navigation (between: --home --detail) {
  @navigation (at: --home) {
    /* Target the clicked link's image */
    :nav-source img {
      view-transition-name: image;
    }
  }
  @navigation (at: --detail) {
    img#hero {
      view-transition-name: image;
    }
  }
}

~

4. Advanced link selection with :link-to()

The spec also introduces ways to style links based on what they link to using the :link-to(...) selector. Its argument is a named route, or url-pattern(). This is incredibly powerful for orchestrating complex UI transitions between routes.

/* Target the all links that links to the --detail route */
:link-to(--detail) {
  color: hotpink;
}

~

We need your feedback!

Over the past months we have given this a lot of thought and have gone back and forth over the key features and their syntax, and now we think we have something that could work. As mentioned we will be presenting this at next week’s CSS Working Group F2F meeting, seeking resolutions to verify with the group that we are down the right path.

Back in June we did an introductory pitch at CSS Day, and a quick read of the room told us this was worth pursuing. Of course we are very open to feedback and would love to hear from you if you have any input.

Are we missing a use case? Do the keywords make sense? Or like one of the open questions we have is about the default base URL be used: should relative links be resolved against the document’s location or the stylesheet’s location?

Please take a look at the current shape of the API and leave your feedback in the w3c/csswg-drafts#12594 at the CSSWG, or reach out to me (or Noam) on social media.

Let’s build this together! 🚀

PS: You can try this out in Chrome Canary with the Experimental Web Platform Features flag enabled 😉

~

Spread the word

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

• 🦋 Bluesky
• 🦣 Mastodon
• 💼 LinkedIn

~

~

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 🙂

~

~