CSS position: sticky now sticks to the nearest scroller on a per axis basis!

If you’ve ever tried to build a data table with a sticky header and a sticky first column, you know the pain. You’d think a simple position: sticky with top: 0 and left: 0 would be enough, but the reality was that only one of both would stick.

A recent change to CSS fixes this: position: sticky now plays nice with single-axis scrollers, allowing you to have sticky elements that track different scroll containers on different axes. This change is available in Chrome 148.

Detect at-rule support in CSS with @supports at-rule(@keyword)

Back in January 2022, I wrote about an exciting new CSS Working Group decision: a function to detect at-rule support using @supports at-rule(@keyword). Fast forward to today, and the CSS Conditional Rules Module Level 5 specification has solidified how this feature works and Chromium (Chrome, Edge, etc.) is about to ship it in Chromium 148!

Introducing view-transitions-mock: A non-visual Polyfill for Same-Document View Transitions

View Transitions are a powerful Modern Web feature allow for smooth seamless animated transitions two between different states of a web page. They can make for a much more pleasant user experience, but as with any new web platform feature, browser support is not yet fully universal so you need to add some fallback logic to your code.

view-transitions-mock bridges that gap. It is a spec-compliant JavaScript implementation of Same-Document View Transitions that polyfills the entire JavaScript API surface of the spec, but that doesn’t do the animation bits.

Using 100vw is now scrollbar-aware (in Chrome 145+, under the right conditions)

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.

How to Find the public WebKit Bug from the Apple-internal rdar:// Bug ID

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?