[css-overflow-4] Allow scrollable overflow to be clipped in off-axis

[flackr]

When developers create scrolling containers that are only intended to scroll in one direction, they'll sometimes have content which slightly overflow in the other axis. Per the css-overflow-3 spec:

The visible/clip values of overflow compute to auto/hidden (respectively) if one of overflow-x or overflow-y is neither visible nor clip.

This seems to mean that even if you set the off axis overflow to clip it will still compute to hidden. While this is not a problem for user scrolling, overflow: hidden is still programmatically scrollable. Calls to scrollIntoView or anchor link scrolls can accidentally vertically scroll to your overflowing content. Worse yet, a user has no way to undo this after it happens.

This originally came up as a scroll-marker bug crbug.com/422733086 (Demo), however this problem can easily occur with existing content. E.g. consider this demo with "accidental" vertical scrolling when clicking on an item to scroll it into view: https://jsbin.com/voxohip/edit?html,css,js,output

Proposal: We should allow overflow clip in the off axis to make that axis not scrollable always at origin. E.g. overflow: auto clip; should allow creating a scroll container which cannot be scrolled vertically. We would still consider it to be a scroll container so long as one axis has a value of hidden | scroll | auto.

[flackr]

@una FYI

[css-meeting-bot]

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.

The full IRC log of that discussion

<TabAtkins> flackr: right now if you specify overflow in one axis, the other is forced to hidden (still programatically scrolalble)
<TabAtkins> flackr: so you can cause accidental off-axis scrolling with JS or a target
<TabAtkins> flackr: i think we should allow making one axis clipped, so it's always at the origin
<TabAtkins> flackr: but otherwise acts like a scroll contianer normally
<TabAtkins> flackr: woudl prevent accidental scrolling
<TabAtkins> fantasai: makes sense
<TabAtkins> TabAtkins: just say that "clip" can be used with the scrollable values?
<TabAtkins> fantasai: would no longer compute to hidden, the element remains a scroll container
<TabAtkins> fantasai: makes sense to me
<TabAtkins> astearns: so not changing current bheavior, just adding new?
<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
<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.
<emilio> q+
<astearns> ack emilio
<TabAtkins> emilio: conceptually i think it seems okay
<TabAtkins> emilio: but this needs a bunch of spec changes to om-view, currently has a binary view of scroll container
<TabAtkins> flackr: it is still a scroll container
<TabAtkins> emilio: yeah, but the scrolling APIs currnetly will still do something
<TabAtkins> flackr: i'll have a look thru cssom-view and see what needs changing
<TabAtkins> emilio: k. i htink we need to change the style adjustment stuff, and change all the things that can scroll.
<oriol> q+
<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
<astearns> ack oriol
<TabAtkins> oriol: there's a bunch of things taht dpened on scroll container or not
<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
<TabAtkins> oriol: automatic min sizes come to mind
<TabAtkins> oriol: not opposed to this change, but there might be some mor eimplications to consider
<TabAtkins> TabAtkins: that makes sense to me
<TabAtkins> astearns: okay, still hearing no opposition. objections?
<fantasai> I think for almost all cases, we will consider to be a scroll container in both axes
<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.