Re: [csswg-drafts] [css-overflow] Should the viewport accept `overflow: clip`? (#12687)

The CSS Working Group just discussed ``[css-overflow] Should the viewport accept `overflow: clip`?``.

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> oriol: in some other issue we resolved that it should be possible for scroll containers to only be scollable in one axis and other to be clip<br>
&lt;ydaniv> ...  common for authors that only want to allow in one axis<br>
&lt;ydaniv> ...  and then in other axis they used hidden, or clip<br>
&lt;ydaniv> ...  what could happen, some JS APIs could scroll there and get broken<br>
&lt;ydaniv> ... we resolved to allow one axis to be clip<br>
&lt;ydaniv> ... currently the logic that propagates the overflow value to the viewport...<br>
&lt;emilio> q+<br>
&lt;smfr> q+<br>
&lt;ydaniv> ... to be consistent we should allow one of the axes to be clip, or both for completeness<br>
&lt;Rossen3> ack emilio<br>
&lt;ydaniv> emilio: to be clear, you're not proposing to avoid having a scroll container on the root, just to be able to scroll in one axis<br>
&lt;ydaniv> oriol: the CSS2 part, keeping it as scroll container with one axis not scrollable<br>
&lt;ydaniv> ... we can keep both things, allow authors to specify one axis not scrollable<br>
&lt;TabAtkins> +1 to Oriol's suggestion. Being able to *accidentally* scroll into off-screen content (but then never having the ability to get back) sucks; the difference between clip and hidden here is just the behavior in certain corner cases, and 'clip' is better there.<br>
&lt;ydaniv> ... for consistency with what we did for elements, we should allow for 1 of the axes to be clipped, that we should consider<br>
&lt;Rossen3> ack smfr<br>
&lt;emilio> q+<br>
&lt;ydaniv> smfr: the root scroller is somewhat special<br>
&lt;ydaniv> ... if someone would do that on the root they could break navigations<br>
&lt;ydaniv> ... might not be a blocker, but need to keep in mind<br>
&lt;Rossen3> ack emilio<br>
&lt;ydaniv> emilio: I think my concern on root not having a scroller is that overflow visible would still create a scroller<br>
&lt;ydaniv> ... if we decide that clip propegates, we should say it still creates a scroll container<br>
&lt;smfr> q+<br>
&lt;ydaniv> ...  it does affect APIs, and what scrolling element to return<br>
&lt;Rossen3> q+<br>
&lt;Rossen3> acl smfr<br>
&lt;Rossen3> ack smfr<br>
&lt;ydaniv> smfr: does that affect the behavior of scrollWidth/Height?<br>
&lt;ydaniv> emilio: that's what I wanted to get at<br>
&lt;ydaniv> ... for overflow: clip shouldn't create a scrollable element<br>
&lt;ydaniv> ... I think that scrollParent would be skipped<br>
&lt;ydaniv> smfr: so going up the tree and not hitting the root would be strange<br>
&lt;ydaniv> oriol: we can say that if both axes are set to clip then hit that<br>
&lt;ydaniv> Rossen3: does that also include selection?<br>
&lt;ydaniv> ... mostly for a11y<br>
&lt;Rossen3> ack Rossen3<br>
&lt;Rossen3> ack Rossen<br>
&lt;ydaniv> oriol: I guess it could be same as elements that only scroll in one axis<br>
&lt;ydaniv> ... I'd say that probably [missed]<br>
&lt;emilio> Wanted to say that preventing both axes from scrolling seems fine as long as we keep saying that the viewport is a scroller<br>
&lt;ydaniv> Rossen3: not quite ready for a resolution<br>
&lt;ydaniv> ... but made some progress, so back to the issue<br>
&lt;ydaniv> ... we can continue next week if we have progress on the issue<br>
</details>


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


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

Received on Wednesday, 10 December 2025 18:01:36 UTC