Csswg-drafts: [css-overflow-4] Add scrollbar-gutter: none

[chrishtr]

Currently the scrollbar-gutter property in CSS overflow level 4 does not allow a version that reserves no space at all for the scrollbar.

This is needed for the use-case of an overlay scrollbar that draws on top of content when present. It was discussed previously in #419 in the context of disabling scrollbars, but there is also the use-case of overlay scrollbars.

@tabatkins

[skobes]

I think this is important, though the reason is subtle. To motivate, consider a page with a full-width solid-color header, on a platform with non-overlay native scrollbars (e.g. Windows, or Mac with certain settings).

With default styles, the page experiences layout instability when appended content causes overflow.

With overflow: scroll, the layout shift is avoided, but without overflow a disabled scrollbar appears, which is ugly.

If the page uses scrollbar-gutter: stable (as spec'ed), it avoids both layout shifts and disabled scrollbars, but the header is unable to occupy the gutter. Without overflow, a white gap would appear to the right of the header, which is (IMHO) as ugly as a disabled scrollbar.

The only way to avoid all of those problems today is with the non-standard "overflow: overlay" (as implemented in Chrome). Having "scrollbar-gutter: none" would give us a standardized equivalent.

[frivoal]

For OS/Browsers with traditional / non-overlay scrollbars by default, are they capable of (and willing to) of switching to overlay if requested?

I expect some OS / UI toolkit may simply lack overlay scrollbars, and in OSes when overlay or not is a user setting (like macOS), there may be reluctance in displaying overlay scrollbars when the author asks for them if that contradicts the user settings.

I guess we could spec it so that support for this value is optional, and so that it is expect to be rejected at parse time (and by @supports) in browsers that won't actually do overlay scrollbars when asked.

[skobes]

This proposal as I understand it forces overlay behavior (i.e. scrollbar obscures content when present), not overlay styling. This wouldn't require any OS support.

[tabatkins]

We've definitely discussed this, but ended up not using it due to WebKit people objecting to it; while they default to "none" behavior with overlay scrollbars, they allow switching it off, and don't want to allow authors to force pages back to overlay against user's wishes. (Florian said essentially this, I'm just making it clearer that this isn't a theoretical; it is based on @smfr and @hober objecting during meetings in the past.)

Having "none" mean that, for such users, they get obscured content (and in a code path that's unlikely to be tested) doesn't sound great. :(

[chrishtr]

Having "none" mean that, for such users, they get obscured content (and in a code path that's unlikely to be tested) doesn't sound great. :(

I think it's fine if the overlay scrollbars are implemented well, where the scrollbar fades away after scrolling is complete.

[frivoal]

Sure, but the point is that some OS vendors will refuse to make scrollbars that fade away after scrolling is complete, because this is in their view a user choice not an author one. Also some OSes do not have that kind of scroll bar.
In that case:

• We can say that they're allowed to display a "normal" (non overlay) scrollbar on top of the content, as suggested in https://github.com/w3c/csswg-drafts/issues/4501#issuecomment-558184710. But this would be bad for users, as the content would be partially obscured.
• We can say that support for this value is optional, and when not supported, it must be rejected at parse time, so that @supports can be used. This is probably doable, but would probably require for some UAs that can have overlay scrollbars, but chose not to in certain modes, to be able to toggle support on and off from the parser at run time, based on that user setting. Not sure if people are willing to do that.

[skobes]

It is bad for users if content is obscured in a way the author does not anticipate. It is not bad if the author designs the page correctly.

The concern in https://github.com/w3c/csswg-drafts/issues/4501#issuecomment-558364434 that the non-overlay code path is "unlikely to be tested" seems to assume content authored exclusively for WebKit. But authors writing for the broader web will test on Windows, where the non-overlay path is the default.

[chrishtr]

I agree that we should not allow a situation where scrollbars overlay content and the user can't fix it.

I just read the spec again, and scrollbar-gutter: stable appears to be the right value for the scrollbar-gutter: none use-case I was thinking of: if overlay scrollbars are present, then reserve no space for the gutter, but always be stable.

Let's close this issue then. I'll leave it open for a few days to see if the reasoning is incomplete.