#1222: Other Spec Review: Single-Axis Scroll Containers

Visit on Github

Opened Apr 24, 2026

Specification

https://github.com/w3c/csswg-drafts/pull/13903

CSSWG discussion: https://github.com/w3c/csswg-drafts/issues/12289

Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-containers

Links

  • A description of the problems that end-users were facing before this proposal:

A common issue web developers run into is creating a table with labels on the top and left sides, and needing to keep those labels visible both as the table scrolls horizontally and the page scrolls vertically. Without this, users can lose context while scrolling large tables, especially on mobile. position: sticky is widely used for this, but it has the limitation that both axes must stick to the same scroller.

Another common issue is when creating a scrollable container that should move in only one direction, developers have no way guarantee that the off-axis stays in place. Historically, when even one overflow axis is given a scrollable value, CSS overflow also converts the other axis to a scrollable value. This leads to issues when calling DOM scroll APIs such as scrollIntoView(), where the off-axis can move unintentionally.

Please see the explainer for details.

  • Alternatives considered:

Explainer Alternatives Considered

  • Examples of how to use the proposal to solve the end-users' problems:

Explainer Proposal and Examples

  • What do the end-users experience with this proposal:

Developers can create real single axis scroll containers matching users expectations when using them. End-users can keep labels on both axes visible as they scroll a large table on a mobile device. They do not see what appears to be a buggy offset of items when navigating to an off-screen carousel item. They see web pages that are easier to understand and use.

wpt.fyi/results/css/css-position/sticky/position-sticky-single-axis-basic.html wpt.fyi/results/css/css-position/sticky/position-sticky-single-axis-dynamic-axis-change-crash.html wpt.fyi/results/css/css-position/sticky/position-sticky-single-axis-dynamic.html wpt.fyi/results/css/css-position/sticky/position-sticky-single-axis-nested.html wpt.fyi/results/css/css-position/sticky/position-sticky-single-axis-used-values.html wpt.fyi/results/css/css-overflow/single-axis-scroll-apis.html

The specification

Where and by whom is the work is being done?

Feedback so far

You should also know that...

None.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1222

Discussions

Log in to see TAG-private discussions.

Discussed May 18, 2026 (See Github)

Xiaocheng: I will also look at this.

Luke: I'm interested as well.

Discussed May 18, 2026 (See Github)

Lola: Also CSS. To Eurasia.

Discussed Jun 1, 2026 (See Github)

Lola: Luke?

Luke: I have not had a chance yet.

Comment by @freedebreuil Jun 4, 2026 (See Github)

Draft spec PR is now available: https://github.com/w3c/csswg-drafts/pull/13903

Discussed Jun 8, 2026 (See Github)

Xiaocheng: Not a big proposal, but a breaking change. Looks like they didn’t estimate the breakage. They have a section about "to minimize compatibility impact," but there is no estimate.

Xiaocheng to draft a response for Luke and others to review.

Discussed Jun 22, 2026 (See Github)

bump

Discussed Jul 6, 2026 (See Github)
<skip>
Discussed Jul 13, 2026 (See Github)

Luke: I don't know how many immediate concerns are jumping out at me. I thought it might impact accessibility in some way.

Matthew: I do want to look at it. Anything with scrolling on one axis is okay.

Luke: It doesn't do the new behaviour. It only uses the new behaviour if you used double key with double index.

Lola: is that enough? If you're a developer, and used key for any pari, is that going to work as extended if this is a breaking change?

Luke: A conversation to have. Worth flagging.

Lola: If it is going to be confusing for webdevs, then we'll probably not mark it as satisfied. Post initial comment.

Comment by @lukewarlow Jul 16, 2026 (See Github)

Hi @freedebreuil, the TAG has discussed this and the new behavior is looking good to us on its own, but we noticed that this is a breaking change. Are there measurements to the impact to the web compatibility, or methods to measure such impacts? We'd like to have that included in the explainer. We'll continue to discuss this and reply with follow-up comments or a resolution when ready.

Comment by @freedebreuil Jul 21, 2026 (See Github)

Thanks @lukewarlow. The breaking change is limited to the case where clip on one axis is combined with a scrollable overflow value on the other (for example, overflow: scroll clip). With single-axis scroll containers, the clip value is now preserved instead of being converted to hidden. Since clip is an explicit opt-out of scrolling for that axis, we expect compatibility issues to be rare.

We added a use counter to track this: SingleAxisScroller

Also, updated the web compatibility section of the explainer to include this information.

Discussed Aug 3, 2026 (See Github)

Luke: we discussed this before and there's a breaking change. But the breaking change is limited (to clip?). I'm convinced that... they have a usage counter that is very high, around 10% but it's unclear what they are using it for, so there's risk if it breaks stuff... so there is a compat risk. Ehsan had some concerns about the compat issue, so maybe he should have a look.

Ehsan: sure, I can have a look.

Luke: If the question is whether developers would be confused by this change, probably not, because this gives better behavior.

Lola: Ehsan will review and we will figure out the closing comment.

Discussed Aug 10, 2026 (See Github)

skip