Re: [csswg-drafts] [css-overflow-5] Allow controlling scroll axis locking behavior (#13207)

The CSS Working Group just discussed `[css-overflow-5] Allow controlling scroll axis locking behavior`, and agreed to the following:

* `RESOLVED: scroll-axis-lock:auto|none, applies to scroll containers, not inherited, UNLESS smfr objects`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: I don't think it's in spec anywhere, but I think all browsers do.. if you scroll a mostly-vertical or horiz direction, we discard the minor component and "lock" you to the axis until you move sufficiently far in the other direction to break out of the lock<br>
&lt;TabAtkins> flackr: this is often a reason devs can't use real scrollers to do map panning, they have to roll their own<br>
&lt;TabAtkins> flackr: i'd like to add a property allowing authors to turn locking off<br>
&lt;TabAtkins> flackr: completely open to names, tho I have a proposal. took values from scroll snap because it feels similar to snapping behavior<br>
&lt;TabAtkins> flackr: other q is, if we had this beahvior, do we want to define an initial behavior, or leave initial up to the browser?<br>
&lt;florian> q+<br>
&lt;TabAtkins> florian: proposal is `overflow-axis-lock: proximity | none`<br>
&lt;TabAtkins> s/florian/flackr/<br>
&lt;astearns> ack florian<br>
&lt;TabAtkins> flackr: we can add "auto" if we want<br>
&lt;TabAtkins> florian: I think i'd rename proximity to auto.<br>
&lt;TabAtkins> flackr: makes sense<br>
&lt;TabAtkins> florian: in the future we can add mandatory, saying you can *only* do single-axis scrolling<br>
&lt;TabAtkins> flackr: that sounds good to me<br>
&lt;fantasai> scribe+<br>
&lt;kizu> +1 to `auto` &amp; the feature itself<br>
&lt;fantasai> TabAtkins: Likely want to leave it undefined, so +1 to auto<br>
&lt;bramus> +1<br>
&lt;TabAtkins> emilio: sounds reasonable<br>
&lt;TabAtkins> florian: for prop name I'd prefer scroll-* rather than overflow-*<br>
&lt;miriam> is *overflow* right? yeah, agree with florian<br>
&lt;TabAtkins> flackr: makes sense<br>
&lt;TabAtkins> florian: scroll-axis-lock:auto|none<br>
&lt;TabAtkins> flackr: yeah that sounds good<br>
&lt;TabAtkins> emilio: and that seems extensible to request locking in only one axis if we want...<br>
&lt;TabAtkins> astearns: so proposed is to add "scroll-axis-lock:auto|none" to overflow 5<br>
&lt;TabAtkins> florian: I presume an inherited property<br>
&lt;TabAtkins> fantasai: dunno, different scoped containers might not want it to inherit<br>
&lt;TabAtkins> florian: maybe you're right<br>
&lt;TabAtkins> florian: yeah i'm wrong<br>
&lt;TabAtkins> astearns: we'll wait for Tess to fetch smfr's opinion<br>
&lt;TabAtkins> florian: I don't remember precedent, but we don't do any silly back-propagation from body to root?<br>
&lt;TabAtkins> flackr: yes<br>
&lt;fantasai> TabAtkins: yeah, we try not to increase back-propagation<br>
&lt;TabAtkins> astearns: let's resolve to add it unless Simon objects<br>
&lt;TabAtkins> RESOLVED: scroll-axis-lock:auto|none, applies to scroll containers, not inherited, UNLESS smfr objects<br>
&lt;TabAtkins> (smfr is here, getting it explained)<br>
&lt;TabAtkins> smfr: I think it's okay<br>
&lt;TabAtkins> florian: that's exactly what you needed to say<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13207#issuecomment-3808193000 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 28 January 2026 00:03:21 UTC