Re: [csswg-drafts] [css-overflow-4] Allow scrollable overflow to be clipped in off-axis (#12289)

The CSS Working Group just discussed `[css-overflow-4] Allow scrollable overflow to be clipped in off-axis`, and agreed to the following:

* `RESOLVED: Allow overflow: clip in other axis of a scrollable container. It is still a scroll container but prevents scrolling away from origin in that axis. Figure out what needs to change to respond to an axis not being scrollable.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: right now if you specify overflow in one axis, the other is forced to hidden (still programatically scrolalble)<br>
&lt;TabAtkins> flackr: so you can cause accidental off-axis scrolling with JS or a target<br>
&lt;TabAtkins> flackr: i think we should allow making one axis clipped, so it's always at the origin<br>
&lt;TabAtkins> flackr: but otherwise acts like a scroll contianer normally<br>
&lt;TabAtkins> flackr: woudl prevent accidental scrolling<br>
&lt;TabAtkins> fantasai: makes sense<br>
&lt;TabAtkins> TabAtkins: just say that "clip" can be used with the scrollable values?<br>
&lt;TabAtkins> fantasai: would no longer compute to hidden, the element remains a scroll container<br>
&lt;TabAtkins> fantasai: makes sense to me<br>
&lt;TabAtkins> astearns: so not changing current bheavior, just adding new?<br>
&lt;TabAtkins> flackr: technically it's a change, if people are using scroll+clip today (it computes to hidden). but should be rare, i think it's safe<br>
&lt;flackr> Proposed resolution: Allow overflow: clip in other axis of a scrollable container. It is still a scroll container but prevents scrolling away from origin in that axis.<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: conceptually i think it seems okay<br>
&lt;TabAtkins> emilio: but this needs a bunch of spec changes to om-view, currently has a binary view of scroll container<br>
&lt;TabAtkins> flackr: it is still a scroll container<br>
&lt;TabAtkins> emilio: yeah, but the scrolling APIs currnetly will still do something<br>
&lt;TabAtkins> flackr: i'll have a look thru cssom-view and see what needs changing<br>
&lt;TabAtkins> emilio: k. i htink we need to change the style adjustment stuff, and change all the things that can scroll.<br>
&lt;oriol> q+<br>
&lt;TabAtkins> TabAtkins: i think we'd change it so say that scroll containers have 1 or 2 scrollable axises, and we'd redefine things to depend on scrollable axises<br>
&lt;astearns> ack oriol<br>
&lt;TabAtkins> oriol: there's a bunch of things taht dpened on scroll container or not<br>
&lt;TabAtkins> oriol: if we're letting a scroll container only be one axis, maybe want to review those things, some might want to depend on it being scrollable in that axis<br>
&lt;TabAtkins> oriol: automatic min sizes come to mind<br>
&lt;TabAtkins> oriol: not opposed to this change, but there might be some mor eimplications to consider<br>
&lt;TabAtkins> TabAtkins: that makes sense to me<br>
&lt;TabAtkins> astearns: okay, still hearing no opposition. objections?<br>
&lt;fantasai> I think for almost all cases, we will consider to be a scroll container in both axes<br>
&lt;TabAtkins> RESOLVED: Allow overflow: clip in other axis of a scrollable container. It is still a scroll container but prevents scrolling away from origin in that axis. Figure out what needs to change to respond to an axis not being scrollable.<br>
</details>


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


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

Received on Wednesday, 20 August 2025 12:55:30 UTC