[css-overflow-4] overflow into the gutter

[frivoal]

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:

1. 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
2. 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
3. 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
4. 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.

[frivoal]

cc: @felipeerias

[chrishtr]

@bfgeek

[felipeerias]

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).

[bfgeek]

@frivoal @tabatkins Can you provide an example for when this would come into effect?

[frivoal]

<div>abcde</div>

div {
  font-size: 16px
  font-family: monospace;
  width: 4ch;
  overflow: auto;
  scrollbar-gutter: stable;
}

Assume with that particular font that 1ch = 8px, which is narrower than the typical 16px width of a scrollbar and its gutter. "abcd" fit within the element's content area, and "e" overflows to the right. with classic scrollbars and scrollbar-gutter: stable, that means into the (empty) 16px gutter.

Do we get a horizontal scrollbar? What about if we had scrollbar-gutter: always instead of stable?

	Classic scrollbars		Overlay scrollbars
	stable	always	stable	always
option 1	no scrollbar *		scrollbar †	no scrollbar
option 2	scrollbar			scrollbar
option 3				no scrollbar

 * not web compatible, unless we make a difference between the case where there is a visible scrollbar in the gutter or not
 † because the overflow goes beyond the 0-width gutter

I think we should do 3. Note that the difference between 2 and 3 only becomes apparent if we have the always value, which is proposed in level 4 but not 3.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] overflow into the gutter, and agreed to the following:

• RESOLVED: overflowing into the gutter of a classic scrollbar triggers scrollable overflow, overflowing into the gutter of a overlay scrollbar does not trigger scrollable overflow

The full IRC log of that discussion

<Frances> Rossen: Moving to scrollbar gutter, some members are not available to discuss topics.
<Frances> Florian: Didn't define so far overflowing into the gutter, do we treat as padding effectively, or an area beyond the padding to have an effect on overflow?
<Frances> Florian: Constrained if overflowing into a scrollbar, could trigger overflow and would have to account for it. If overflowing into the gutter of a classic scrollbar, might not trigger overflow. Could trigger instability.
<Frances> Florian: Classic scrollbars could have the same answer, if overflowing into classic scrollbar, if overflowing into overlay scrollbar. Nuance of scrollbar gutter only has the stable value. A value to reserve for space in overlay scrollbars.
<TabAtkins> Sounds reasonable to me.
<flackr> q+
<Frances> PROPOSAL: overflowing into the gutter of a classic scrollbar triggers scrollable overflow, overflowing into the gutter of a overlay scrollbar does not trigger scrollable overflow
<astearns> ack flackr
<Rossen_> ack flackr
<Frances> flackr: Layout of the site could be affected
<Frances> Florian: Will be accessible regardless, can scroll though the content anways.
<Frances> flackr: Different platforms could be affected.
<Frances> Florian: Not necessarily
<Frances> RESOLVED: overflowing into the gutter of a classic scrollbar triggers scrollable overflow, overflowing into the gutter of a overlay scrollbar does not trigger scrollable overflow

[dholbert]

I think maybe the following is a testcase that doesn't have the "assume you have a particular font with these sizing characteristics" special-requirement of Florian's example above:

div {
  width: 80px;
  overflow: auto;
  scrollbar-gutter: stable;
  border: 1px solid black;
}
span.filler {
   display: inline-block;
   width: 79px;
   height: 50px;
   border-right: 2px solid cyan;
   box-sizing: border-box;
}

<div><span class="filler"></span></div>

Live jsfiddle: https://jsfiddle.net/dholbert/s13f9rde/

(Notably, .filler is 1px skinnier than its parent, which means it will almost certainly intrude into the parent's reserved scrollbar-gutter area. And .filler has a 2px border-right to help you see whether its right edge is visible vs. whether it's been clipped by having been treated as overflow.)

If I'm understanding the resolution correctly: for a browser with classic scrollbars, then today's CSSWG resolution means the following:

• the cyan border-right should be treated as overflow and get covered up by the scrollbar-gutter (so you shouldn't see any cyan initially)
• there should be a horizontal scrollbar that you can use to scroll to bring it into view.

@frivoal can you confirm whether I'm getting that right?

(Firefox matches those expectations right now. Chrome and WebKit seem not to match.)

[frivoal]

Side note:

(Firefox matches those expectations right now. Chrome and WebKit seem not to match.)

You need to turn a preference on in Safari for scrollbar gutter to work at all, but once you do, it (mostly) matches Firefox, not Chrome.

(Mostly, because the horizontal scrollbar is drawn differently within its gutter, but that's out of scope here).

---

@dholbert Interesting. This was less obvious that I thought. My first intuition was that you were right.

But then again, the spec says:

When the scrollbar gutter is present but the scrollbar is not, or the scrollbar is transparent or otherwise does not fully obscure the scrollbar gutter, the background of the scrollbar gutter must be painted as an extension of the padding.

Descendants of an element that overflow into its padding area are painted over the background, not under, so this part doesn't seem true:

the cyan border-right should be treated as overflow and get covered up by the scrollbar-gutter (so you shouldn't see any cyan initially)

So, as far as I can tell, the layout is correct in Firefox/Safari (presence of a horizontal scrollbar), but the painting is correct in Chrome (cyan thing visible on top of the gutter).

The fully correct solution is a little counter intuitive: you'd be able to see the cyan bar AND you'd get a scrollbar to bring in into out of overflowing onto the padding. That's may seems a little unnecessary to have it be visible and have a horizontal scrollbar, but the alternatives seem worse:

• change the spec to ask for what Firefox and Safari do, and paint the gutter on top of (inflow) descendants, but it seems unnecessary to obscure them.
• change the spec to ask for what Chrome does, but then the layout isn't stable: if for some (unrelated) reason we need to add a scrollbar into that gutter, then the content gets obscured, and we would need to add a scrollbar in the other dimension to be able to get to it, and this instability of the presence of the other scrollbar doesn't seem great.

Does that make sense, or do you think I missed something?

[wangxianzhu]

"The fully correct solution" above sounds good to me.

I'm wondering if we can make it work by modifying the definition of scrollable overflow to include the empty scrollbar gutters, as if they are a part of the padding box, which will be consistent with "the background of the scrollbar gutter must be painted as an extension of the padding".

Maybe we should also clarify that the scrollport should not be affected by empty scrollbar gutters, to get the correct paint behavior. It seems that Safari and Firefox shrink the scrollport with the empty scrollbar gutters.