~

~

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

A recent change to CSS fixes this issue: position: sticky can now track the nearest scrolling container per axis.

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 computes overflow-y 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

Chromium (Blink)

✅ Available in Chromium 148.0.7742.0.

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

~

~

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

👨‍🔬 Available in Chromium 148.0.7742.0 or newer behind the Experimental Web Platform Features flag (chrome://flags/#enable-experimental-web-platform-features).

No word yet on which stable version will ship it by default. The paperwork is in progress. Subscribe to CrBug #491829958 for updates.

Firefox (Gecko)

✅ Supported in Firefox 150

Firefox 150 is expected to go stable on April 21, 2026

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):

@supports (background-image: light-dark(linear-gradient(white, white), linear-gradient(black, black))) {
  /* 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 … */
}

~

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! …)!

~

~

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 https://www.bram.us/2026/01/15/100vw-horizontal-overflow-no-more/ https://www.bram.us/2026/01/15/100vw-horizontal-overflow-no-more/#comments Wed, 14 Jan 2026 23:20:21 +0000 https://www.bram.us/?p=36008 From Chrome 145 onwards, 100vw will automatically subtract the size of the (vertical) scrollbar from it if you have forced the html element to always show a vertical scrollbar (using overflow[-y]: scroll) or if you reserve space for it (using scrollbar-gutter: stable). The same applies to vh with a horizontal scrollbar, as well as all small, large, and dynamic variants.
]]>

From Chrome 145 onwards, 100vw will automatically subtract the size of the (vertical) scrollbar from it if you have forced the html element to always show a vertical scrollbar (using overflow[-y]: scroll) or if you reserve space for it (using scrollbar-gutter: stable). The same applies to vh with a horizontal scrollbar, as well as all small, large, and dynamic variants.

~

The problem with CSS Viewport Units

The problem with CSS Viewport Units (vw and friends) is that those units do not take the presence of classic scrollbars into account. So when you size something to be 100vw wide, it is sized to fill up the entire viewport width … which can cause overflow when there is a vertical scrollbar present.

In the following screenshot of this demo, the blue box is sized to be 100vw wide. Because of the presence of the vertical scrollbar (which reduces the viewport’s final width) the blue box becomes too wide for it to fit inside the “viewport with scrollbar taken into account”, causing the horizontal scrollbar to appear.



This “pointless” horizontal scrollbar lead Šime Vidas filing this issue at the CSS Working Group in 2021.

~

Cycles

A gut reaction to this “pointless” horizontal scrollbar problem is that CSS is stupid and that viewport units should simply take the presence of the scrollbar into account. The problem there is that this can’t “just” be done, because of cycles.

Say you have a page that contains only a box that is sized to be 100vw × calc(100vh + 1px). With classic scrollbars, this results in the page overflowing in both directions. If the vw unit were to adjust itself by subtracting the scrollbar size in that case, you’d be stuck with the following cyclic behavior:

1. Page is overflowing vertically (because of the calc(100vh + 1px))
2. Browser shows the vertical scrollbar
3. Page is now also overflowing horizontally (because of the 100vw)
4. Browser subtracts the scrollbar sizes from the viewport units on both axis
5. Page is no longer overflowing horizontally
6. Browser no longer shows the horizontal scrollbar
7. Browser no longer subtracts the scrollbar size from the vh unit after all
8. Go back to step 1

So no, simply subtracting the scrollbar’s size isn’t a viable solution here.

~

Always-present scrollbars (or scrollbar gutters)

A thing Firefox had back in the day – but that it later removed because it wasn’t interoperable (source) – was that they did subtract the size of the scrollbar from the vw unit, but only when the page was set to always show its scrollbars, which could be triggered by declaring overflow-y: scroll on it.

This approach actually works, because the presence of the vertical scrollbar is unconditional in that case – it is always present.

1. Browser shows the vertical scrollbar, regards of whether the page is currently overflowing or not
2. Subtract the scrollbar size from the vw unit
3. No need to show a horizontal scrollbar

At the end of 2023 we resolved with the CSS Working Group to resolve on this behavior:

RESOLVED: if overflow: scroll is set on the root element (not propagated from body), account for the default scrollbar width in the size of vw. […]

So that means that if you have overflow-y: scroll declared on html it will take the size of the vertical scrollbar into account for determining the value of 100vw. The same applies to the vh-unit and the horizontal scrollbar.

What is also interesting, is that with the CSS Working Group we also resolved to take scrollbar-gutter: stable (on the root) into account as a trigger for this.

RESOLVED: […] Also take scrollbar-gutter into account on the root.

My suggestion to you here would be to declare scrollbar-gutter: stable over overflow-y: scroll on html, because the latter always draws a scrollbar, even when not necessary.

Translated: Put this in your CSS reset if you hadn’t done so already:

html {
  scrollbar-gutter: stable;
}

~

Don’t break the web

It took some more back and forth after the original resolution was taken because there were concerns that this would break existing websites: if a site already manually subtracted the (guesstimated) scrollbar-size from 100vw, they would visually break.

Early 2024 I ran the numbers by querying the HTTP Archive to see how many sites actually used the calc(100vw - var(--scrollbar-width)) pattern in combination with overflow: scroll declared on html.

In total 12,089,606 root pages found in the HTTP Archive November 2023 Dataset were scanned. Out of those +12 million scanned pages:

• 324,866 use the calc(100vw - <length>) pattern (2.6871512603%)
• 4,112 have overflow: scroll _declared_ on the root element (0.03401268825%)
• 72 pages use both (0.0005955529072%)

Of those 72 pages, only 38 seem to use the calc() expression to cater for scrollbars (0.0003143195899%). The ignored 34 pages did a calculation with a <length> greater than 50px which seems like an unlikely width for a scrollbar to have.

That number is small enough to justify this breaking change to be introduced – especially because it doesn’t lead to data-loss and the origins that use it were not part of the top 1000 websites – so with the CSS Working Group we took a second resolution mid 2024 to continue with this plan.

~

Scrollbar-aware viewport units are available in Chrome 145

I was happy to see that last summer the CrBug concerned with this got assigned, and that the CLs to fixing this followed soon (thanks, David!). All necessary CLs landed in November / December 2025, and on the very last day of 2025 the issue got marked as fixed 🎉

This week Chrome 145 goes to beta. This release includes the change as described above: viewport units are now scrollbar-aware if document scrollbars are forced on the opposing axis or if space for a scrollbar is reserved.

In Chrome 145, the demo shown earlier renders like this, without any “pointless” horizontal scrollbar:



Currently, Chromium-based browsers are the only browser to support this. Unfortunately there is no CSS-only way to feature detect this change.

~

🔥 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/15/100vw-horizontal-overflow-no-more/feed/ 2 https://www.bram.us/2025/12/13/finding-webkit-bugs-using-the-rdar-id/ https://www.bram.us/2025/12/13/finding-webkit-bugs-using-the-rdar-id/#comments Fri, 12 Dec 2025 23:36:56 +0000 https://www.bram.us/?p=35977 If you read the Safari release notes – like the Safari 26.2 release notes – you see a lot of trailing “(12345678)”-mentions in the list of fixed bugs. These numbers are Apple-internal bug IDs, as used within Apple’s internal bug tracker (fka?) named “Radar”.

These numbers are not linked to anything because Radar is Apple-internal, so to external people these numbers are practically useless … or are they?

]]>

If you read the Safari release notes – like the Safari 26.2 release notes – you see a lot of trailing “(12345678)”-mentions in the list of fixed bugs. These numbers are Apple-internal bug IDs, as used within Apple’s internal bug tracker (fka?) named “Radar”.

These numbers are not linked to anything because Radar is Apple-internal, so to external people these numbers are practically useless … or are they?

~

The need for more info

The thing is, that I sometimes like to look up some details behind something. For example, if I see the following in the release notes, then I’d like to know what the bug exactly was, and maybe also how it got fixed.

Fixed flickering of elements with slow-painting content during view transitions. (160886647)

The only info you get there is the Radar ID, which is 160886647 in this example.

Thankfully the WebKit commits always include a mention of this Radar ID in the commit message. Additionally, the public WebKit bugs also mention it in a comment made by the “Radar WebKit Bug Importer” bot. Using the GitHub and Bugzilla search functionality, you can find your way to the commit and public bug.

~

Finding the Git commit

The Radar ID is mentioned in Git commits in the form of rdar://NUMBER. Leveraging GitHub’s search option and limiting it to only the WebKit/WebKit repo and only commits, you can find the commit linked to the Radar ID.

For example, when searching for rdar://160886647, you get this list:



The direct search URL to use is the following:

https://github.com/search?q=repo%3AWebKit%2FWebKit++%27rdar%3A%2F%2FNUMBER%27&type=commits

When clicking through you see all details of the commit.



In both views, you can also find your way to the public WebKit bug.

For reasons unknown to me, not all Radar IDs can be found. For example a commit for 163571747 is nowhere to be found.

~

Finding the public WebKit Bug

In addition to finding the public WebKit Bug through the GitHub commit, you can also find it on WebKit’s public bug tracker which is powered by Bugzilla.

You can’t find the bug using the default search though, because the Radar ID is not mentioned in the bug report itself nor is it listed as a separate metadata field. The Radar ID can be found in an automated comment in the form of <rdar://problem/NUMBER> left by the “Radar WebKit Bug Importer” bot.

To find the bug on Bugzilla, you have to do an advanced search and look for comments that contain that specific string. For example, when doing an advanced search for rdar://problem/160886647, you get this list:



The direct search URL to use it the following:

https://bugs.webkit.org/buglist.cgi?bug_status=RESOLVED&f1=longdesc&list_id=12814258&o1=equals&query_format=advanced&v1=%3Crdar%3A%2F%2Fproblem%2FNUMBER%3E

From the list, we can click through to the bug itself, where you can indeed see the comment by the “Radar WebKit Bug Importer”:



~

Pro Tip: Register a custom Site Search shortcut in Chrome for easy Radar ID lookup

One of the nice features of Chrome is that it allows you to define a Site Search shortcut (fka Custom Search Engine) by which you can search sites. The cool part is that you’re not really limited to search only, and that you can abuse these Site Search shortcuts to become more productive.

For example, I have a rdar Site Search shortcut that immediately searches the WebKit/WebKit repo for the rdar://NUMBER pattern using the number I pass into it. With it, I just type rdar followed by a space and then the Radar ID in the Chrome address bar. Once I hit enter Chrome will navigate to the GitHub search page and find me the commit linked to that Radar ID 🙂

Pretty easy, right?

To add this to Chrome yourself, navigate to chrome://settings/searchEngines and find the “Site Search” section. There, click on the “Add” button to add a new Site Search short with the following details:

• Name: Radar
• Shortcut: rdar
• URL: https://github.com/search?q=repo%3AWebKit%2FWebKit++%27rdar%3A%2F%2F%s%27&type=commits

The Name field doesn’t really matter there, but the Shortcut is the keyword that you will be typing in your address bar followed by a space.



I have use the URL to search GitHub here. You can also use the WebKit link I provided above. Be sure to replace NUMBER in it by %s, which is what Chrome will replace by the “search term” when using it.

~

🔥 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/2025/12/13/finding-webkit-bugs-using-the-rdar-id/feed/ 1