CSS scrollbar-gutter

[felipeerias]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: CSS scrollbar-gutter
• Specification or proposal URL: https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

• TAG review: CSS Overflow: scrollbar-gutter w3ctag/design-reviews#520
• Explainer: https://github.com/felipeerias/scrollbar-gutter-explainer

The scrollbar-gutter CSS property provides control over the presence of scrollbar gutters (the space which may be reserved to display a scrollbar).

This gives Web authors more agency over how their layouts interact with the scrollbars provided by the browser, so they can e.g. prevent excessive layout changes as content expands while avoiding unwanted visuals when scrolling isn't needed.

[annevk]

cc @dholbert @emilio

[emilio]

I think this property should not affect overflow: clip at all, but other than that the functionality here seems reasonable. How does this relate to the Blink-only overflow: overlay and co?

Also are we sure we want gutters when overlay scrollbars are in effect? At least on mac and android the overlay scrollbars are auto-disappearing, so I'm confused about when forcing a gutter to appear would be useful.

[emilio]

w3c/csswg-drafts#6028 for the overflow: clip issue. I think that's just a spec issue.

[felipeerias]

Thank you very much for your feedback @emilio

The main use case for the force keyword is to align elements that are outside a scrolling container (header, toolbox, decorations...) with the contents inside of it, so that both line up visually. Therefore, I think that it would make sense to apply it to elements with overflow: clip as well.

This is a quick example where I have used scrollbar-gutter to align the texts and images: screenshot, source. The image elements are actually as wide as the scrolling containers, but scrollbar-gutter lets me add just the right amount of spacing on their sides so that they match the scrolling content.

The always keyword is mainly intended to fix cases where an overlay scrollbar would obscure the content. For example, this would be hard to use on a browser with overlay scrollbars: https://jsbin.com/bulidiv/edit?html,css,output

That last example was taken from this comment by @frivoal, which provides a far more detailed explanation: w3c/csswg-drafts#4674 (comment)

overflow: overlay has been deprecated in WebKit (bug) and seems to be on its way out in Chromium as well (bug).

[emilio]

But what scrollbar width do you use for the gutter? The scrollbar-width of the overflow: clip element is meaningless, since overflow: clip elements are not scroll containers.

[emilio]

As in, if it applies to overflow: clip, I don't see why it shouldn't apply to overflow: visible. And in that case, we should define what scrollbar size is used in that case.

[felipeerias]

According to the spec, the same rules apply to hidden, visible and clip: scrollbar-gutter will not have an effect unless the force keyword is used (and in that case, it will only reserve the space).

You raise a very good point regarding the size of scrollbar gutters. In Chromium, it is straightforward to take the size of the scrollbar gutter from the current theme because all the scrollbars in the page have the same thickness. However, in Firefox this is not the case because it already implements the scrollbar-width property.

IMHO, it would be reasonable to let scrollbar-width determine the size of scrollbar-gutter even in non-scrollable elements, but the spec should be explicit about this.

[emilio]

In WebKit / Blink it doesn't seem straight-forward either? Those browsers support ::-webkit-scrollbar, right? I think it's weird to apply this property to non-scrollable boxes.

[emilio]

(and you raise a good point, I had overlooked that the spec also mentioned visible, whoops!)

[felipeerias]

This is how the "hypothetical" scrollbar thickness for an element is calculated in Chromium:

1. if the element already has a scrollbar in the desired orientation, return its thickness
2. otherwise, if the element has a custom scrollbar style, use that
3. otherwise, use the page scrollbar theme

(This logic was already in place when I started working on scrollbar-gutter.)

[felipeerias]

I have added several examples to the scrollbar-gutter explainer: https://github.com/felipeerias/scrollbar-gutter-explainer#examples

These should run well in Chrome after enabling the "Experimental Web Platform features" in chrome://flags

For convenience, I have also added screenshots for each one when using fixed and overlay scrollbars.

[felipeerias]

I would like to request an updated position on scrollbar-gutter.

The initial concerns with scrollbar-gutter were eventually solved in a CSS WG meeting where it was agreed to reduce the scope of this property to the functionality that could gather unanimous support among the browser representatives.

The updated spec can be summarized as follows:

• the syntax of scrollbar-gutter becomes auto | stable && both-edges?, where
  • auto keeps the default behaviour;
  • stable reserves space for a classic scrollbar along the inline edge when the overflow value of the box is auto, scroll, or hidden;
  • both-edges reserves a symmetrical space on the opposite edge.
• with overlay scrollbars, scrollbar-gutter does not have any effect.

References and meeting minutes:

• https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
• https://github.com/felipeerias/scrollbar-gutter-explainer
• [css-overflow-4] scrollbar-gutter is too complex w3c/csswg-drafts#4674 (comment)
• [css-overflow-4] rename scrollbar-gutter:both w3c/csswg-drafts#6349 (comment)

Thank you so much.

[emilio]

@felipeerias to be clear, both-edges also works only on scroll containers in the Blink implementation, as per spec, right?

But yeah, I'm pretty happy with the result of all those discussions in the working group, and I think the new spec is pretty reasonable. Thanks for pushing this forward Felipe!

[felipeerias]

@emilio Yes, the implementation follows the standard.

Thank you very much for your valuable feedback!