~

~

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.

~

# 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.

~

# 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 and a recording 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.

~

~

The Challenge: Writing Future-Proof Code

When using new APIs like the View Transition API, you need to write defensive code that check for browser support:

if (!document.startViewTransition) {
  updateTheDOM();
} else {
  document.startViewTransition(updateTheDOM);
}

This clutters your codebase with if (document.startViewTransition) guards which makes it harder to maintain. And that list of safeguards quickly grows, for example when you throw View Transition Types in the mix.

~

The Solution: view-transitions-mock

Ideally, you want to write code that will work seamlessly in all browsers, regardless of whether they support Same-Document View Transitions natively or not. The bridge that gap I created view-transitions-mock, a non-visual polyfill that mocks the entire JavaScript API surface of Same-Document View Transitions, including:

• document.startViewTransition()
• The ViewTransition class, including:
  • The updateCallbackDone, ready, and finished promises.
  • The ViewTransition.transitionRoot property.
• document.activeViewTransition
• View Transition Types

What it doesn’t polyfill are the visual aspects: the pseudo-tree, the CSS properties, and the animations themselves. This means that while you won’t see any animations in browsers without native support, yet your code will still execute without errors, and the DOM will be updated as expected.

~

Getting Started

Using view-transitions-mock is incredibly simple. First, install it from npm:

npm i view-transitions-mock

Then, import and register it in your code (before calling document.startViewTransition):

import { register } from "view-transitions-mock";
register();

That’s it! You can now use the View Transition API without any worries.

import { register } from "view-transitions-mock";
register();

document.startViewTransition(() => {
  // …
});

~

Tweaking the registration

By default, the registration of view-transitions-mock checks whether document.startViewTransition and View Transition Types are supported or not. When both are natively supported, it won’t register the mock.

You can tweak the registration by passing an object with the following properties into the register function:

• requireTypes (Boolean, default value: true): Require support for View Transition Types
• forced (Boolean, default value: false): Force register the mock, regardless of support.

For example, if you are not relying on View Transition Types, call register as follows so that it does not register the mock in Firefox 144–146 (which does not have support for View Transition Types):

import { register } from "view-transitions-mock";
register({ requireTypes: false });

Or if you want to disable native support for Same-Document View Transitions entirely – handy if you want to test how your site looks without View Transitions – call register as follows:

import { register } from "view-transitions-mock";
register({ forced: true });

~

See it in Action

Over at https://chrome.dev/view-transitions-mock you can find a live demo of view-transitions-mock. Every time you click the area around the box a View Transition gets started and output is added to the log.

By default won’t see much happening in the demo, because the thing that you should be seeing is that it doesn’t crash in browsers with no support for Same-Document View Transitions. You can use one of the buttons on the page to do a forced registration of view-transitions-mock. After having done so, you’ll see stuff get added to the log, but no visual transition happening. This is the view-transitions-mock in action!

The source code for the demo is also available in the repository.

~

To learn more about view-transitions-mock, check out the following links if you haven’t done so already:

• view-transitions-mock Source (GitHub) →
• view-transitions-mock Demo →
• view-transitions-mock on NPMJS →
• view-transitions-mock on npmx →

~

~

~

~

The problem

When the browser chooses one of the position-try-fallbacks to apply to an anchored element, the position-area’s Computed Value changes to that chosen fallback. This change is abrupt and in response the anchored element simply jumps from the old position-area to the new position-area. This change can’t be animated using CSS because position-area is discretely animatable (or rather: it’s currently defined as “TBD”, see w3c/csswg-drafts#13577), so the value just flips midway the transition.

.tooltip {
	position: fixed;
	position-area: block-start;
	position-try-fallbacks: flip-block;
	transition: position-area 0.2s ease; /* This doesn’t do anything visually … */
}

~

The technique

Back in 2024 I explored a technique to automatically trigger a View Transition whenever a CSS property changes. For this I relied on @bramus/style-observer which is a StyleObserver that allows you to respond to Computed Value changes in JavaScript. In the StyleObserver’s callback, I reset the targeted element to the previously recorded value, and then start a View Transition to the new value of that property.

For Anchor Positioning specifically, it’s sufficient to monitor the position-area property, as its Computed Value changes whenever a new position-try-fallback gets applied. To make sure that the View Transition is started from the previously recorded position-area, the position-try must be unset temporarily at the start of the View Transition. Therefore, that property also needs to be monitored.

import StyleObserver, { ReturnFormat, NotificationMode } from "@bramus/style-observer";

const $element = document.querySelector('.tooltip');

let isBusy = false;
const styleObserver = new StyleObserver((mutations) => {
	// Prevent double runs
	if (isBusy) return;
	isBusy = true;

	const positionArea = mutations['position-area'];
		
	// No change, do nothing
	if (!positionArea.previousValue || !positionArea.changed) {
		isBusy = false;
		return;
	}
		
	// Move the element back its old location
	// This is done by forcing the old recorded positionArea
	// but most importantly by also unsetting the `position-try`
	$element.style.positionTry = 'none';
	$element.style.positionArea = positionArea.previousValue;

	// Restore the new positions
	const t = document.startViewTransition(() => {
		$element.style.positionTry = '';
		$element.style.positionArea = '';
	});

	isBusy = false;
},
{
	properties: ['position-area', 'position-anchor', 'position-try'],
	returnFormat: ReturnFormat.OBJECT,
	notificationMode: NotificationMode.ALL,
});

styleObserver.observe($element);

Here is a live demo that is using this technique:

See the Pen CSS Anchor Positioning: Animating `position-area` with View Transitions, powered by @bramus/style-observer by Bramus (@bramus) on CodePen.

Scroll the page up and down to trigger a different position-area on the positioned element.

~

Known Issues

Unfortunately there are some issues with the technique:

1. The code does not work in Firefox.

   I initially thought this was because of position-area being underspecified in the spec – it’s animation type is currently specced as “TBD” – and that Firefox therefore did not mark the property as being Discretely Animatable. A look at Stylo’s source code tells me it is defined as a discretely animatable property so so that’s not the problem.

   Digging into the code of my StyleObserver, I see it only picks up the initially applied value of position-area but no subsequent changes, even though a getComputedStyle() indicates that the value did change. I think there is a bug on Firefox’s end in which it does not trigger a transition when the value changes as the result of a position-try-fallback being chosen.

   I have filed w3c/csswg-drafts#13577 at the CSSWG to fix the spec, and https://bugzilla.mozilla.org/show_bug.cgi?id=2020592 with Firefox to get the bug sorted on their end.

2. Chrome is affected by a 1-frame glitch due to the ambiguously defined timing of transitionrun. w3c/csswg-drafts#11665 is concerned with this.

3. In Safari, the transitionrun that tracks position-area keeps firing over and over once it has detected a change. This is fixed in Safari Technology Preview.

4. While the View Transition is running, the positioned and anchored elements can feel a bit out-of-sync. This is because of how View Transitions deal with scroll: during a scroll, VTs retarget the end transform of the ::view-transition-group() pseudos, which makes them be subjected to the animation-duration instead of changing instantly. In w3c/csswg-drafts#10197 I am throwing around ideas to get this fixed.

All these issues are fixable over time, but I would say that the 1-frame glitch in Chrome is preventing this from being something that is really usable right now.

Also note that the anchor in the demo does not change aspect ratio when a new position-area gets set. If yours does, you’ll need this code by Jake.

~

~

Table of Contents

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

~

# The Talk

This talk was a brand new talk (which I had rehearsed at PHPAntwerp just 2 days before) about CSS Anchor Positioning. It’s a high-energy, fast-paced talk that packs a lot of information in ±30 minutes.

We’ve all been there. You need a popover to attach to a button, but they aren’t parent/child. You end up reaching for JavaScript, calculating coordinates, and wrestling with viewport edges. CSS Anchor Positioning is a recent API designed to solve exactly this. This talk is a practical, down-to-earth look at how it works. We’ll explore the anchor() function, the position-anchor and position-area properties, and @position-try to build UIs that are truly context-aware and robust, all without the JS hacks.

~

# 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.

All the Anchoring demos that I built are gathered in this CodePen Collection.

~

# Recording/Video

The talk was recorded and is embedded below:

The recording comes wiht subtitles and you can find a transcript on the SotB site itself.

~

# Thanks!

Thanks to Web Standards London for organizing State of the Browser, with a special shout-out to Dave (MORE ACID!). Similar to previous years, they’ve managed to curate a nice line-up of talks, with the right balance between practical/inspirational, known/new speakers, etc – It was an honor to get to open the conference with this technical deep dive.

It was wonderful catching up with familiar faces (Jake! Cassie! Jeremy! Zach! Keith! Luke! Ryan! Josh! PPK! Niels! Alex! Estelle! Sophie! Sara! Manuel! …) and finally meeting those of you I’ve only known online until now (Oliver! Pavel! James! Josh! …)!

~

We’ve all been there. You need a popover to attach to a button, but they aren’t parent/child. You end up reaching for JavaScript, calculating coordinates, and wrestling with viewport edges. CSS Anchor Positioning is a recent API designed to solve exactly this. This talk is a practical, down-to-earth look at how it works. We’ll explore the anchor() function, the position-anchor and position-area properties, and @position-fallback to build UIs that are truly context-aware and robust, all without the JS hacks.

I also gave this talk at State of the Browser 2026, just a few days later. You can find the slides and a recording of the talk in the State of the Browser post.

~

~

The feature is available in preview behind a feature flag. First you need to flip the flag (to enable the feature) and then choose the vertical tabs layout (to apply the feature):

1. Navigate to chrome://flags/#vertical-tabs
2. Set the dropdown to enabled
3. Relaunch Chrome
4. Right click the tabbar and choose “Move Tabs To The Side”

Here’s screenshots:





If you want, you can collapse the tabs bar to a minimal form, as shown at the top of this post.

~

🔥 Like what you see? Want to stay in the loop? Here's how:

• 🦋 Follow @bram.us on Bluesky
• 🔸 Follow bram.us using RSS

I can also be found on 𝕏 Twitter and 🐘 Mastodon but only post there sporadically.

]]> https://www.bram.us/2026/01/16/chrome-145-adds-experimental-support-for-vertical-tabs/feed/ 0