If an element has a scrollbar gutter on its inline end side, and some content of that element (or its children) that would qualify as scrollable overflow extends into the gutter (but not beyond), do we consider that:
The gutter is kind of an extension of the padding, and overflowing into the padding in the inline axis doesn't cause a need for scrollbars, so this doesn't either
the gutter is after the padding, and normally things extending outside a box’s padding edge get a scrolling mechanism (per https://drafts.csswg.org/css-overflow-3/#scrollable), so if you overflow into the right gutter, you should get a horizontal scrollbar to be able to scroll to that content
we should do 1 if the scrollbars are overlay, and 2 if the scrollbars are classic, because that's what you need to be able to see the content
something else?
A strict interpretation of 1 is wouldn't be web compatible: a the very least we need a scrollbar to access content that goes into a gutter in which there is a visible classic scrollbar, since that's the legacy behavior, and since otherwise, that content would be unreachable.
For stability's sake, I think we should extend that to stable gutters with classic scrollbars even when the scrollbar is not visible (i.e. overflow:auto and no overflowing content in the block axis). Same thing for always gutters, since in the case of classic scrollbars, they're the same as stable ones. So that would mean doing 3.
We could also do 2, but that doesn't seem useful / necessary.
The text was updated successfully, but these errors were encountered:
I agree with @frivoal's analysis. Doing 3 seems a reasonable option.
My only concern is the interaction between this behaviour and the proposed match-parent value at #5232 (although on a first look both seem compatible).
If an element has a scrollbar gutter on its inline end side, and some content of that element (or its children) that would qualify as scrollable overflow extends into the gutter (but not beyond), do we consider that:
A strict interpretation of 1 is wouldn't be web compatible: a the very least we need a scrollbar to access content that goes into a gutter in which there is a visible classic scrollbar, since that's the legacy behavior, and since otherwise, that content would be unreachable.
For stability's sake, I think we should extend that to
stable
gutters with classic scrollbars even when the scrollbar is not visible (i.e.overflow:auto
and no overflowing content in the block axis). Same thing foralways
gutters, since in the case of classic scrollbars, they're the same asstable
ones. So that would mean doing 3.We could also do 2, but that doesn't seem useful / necessary.
The text was updated successfully, but these errors were encountered: