[css-overflow] scrollbar-gutter should not do anything for non-scrollable boxes

[emilio]

https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property:

When the force keyword is present stable and always take effect when overflow is visible, hidden or clip in addition auto or scroll. This does not cause a scrollbar to be displayed, only a scrollbar gutter.

Why? overflow: clip doesn't create an scrolling box, so it seems weird scrollbar-gutter somehow affects this.

[tabatkins]

Neither does overflow: visible, but we have it take effect there, too.

[emilio]

Is that useful? That seems weird that now stuff like scrollbar-width or the weird ::-webkit-scrollbar pseudos would have an effect on non-scrollable boxes.

[felipeerias]

It only has an effect when used with the force keyword, otherwise it is ignored.

The reason for this is to be able to align content outside of a scrolling box (header, toolbar...) with content inside of it.

[emilio]

I still think it's wrong. How does it affect inline elements? Svg?

[felipeerias]

According to the spec, it should apply to all elements. Perhaps that should be more specific.

In the Chromium implementation, it affects some inline elements (like images) pretty much like it does block elements: the width of the element remains the same, but there is an additional space reserved along one of or both of the inline edge (kind of like setting a padding on an element with box-sizing: border-box).

[MatsPalmgren]

What's the use case for applying this property on non-scrollable boxes?

[emilio]

Right, I meant non-replaced inline boxes. I think instead of playing whackamole with all different layout types there are this property should not only apply to scrollable boxes. If authors want to do something based on scrollbar sizes like moving content around or what not, we can add environment variables exposing the platform scrollbar size, which is both easier to specify and to implement, and more flexible.

[tabatkins]

What's the use case for applying this property on non-scrollable boxes?

As stated a few comments back:

The reason for this is to be able to align content outside of a scrolling box (header, toolbar...) with content inside of it.

It also lets you keep a stable layout if your app can switch a box from being non-scrollable to scrollable for some reason. (For example, having an editable area initially be inert and overflow:hidden, then switch overflow:auto when activated. Possible use-case: GitHub diff displays when you have lots of files in the diff.)

---

I think instead of playing whackamole with all different layout types there are this property should not only apply to scrollable boxes.

We do need to exclude non-replaced inlines, but that's all the whackamole that we could possibly have. Scrollbars aren't something special-cased across display modes. I think the property should just be clarified to "all elements capable of displaying scrollbars", perhaps with this detailed in prose to mean anything that will display a scrollbar if set to overflow:scroll.

[emilio]

I disagree. In Gecko at least, the way we implement scrollers is a different box altogether (wrapping the scrolled content).

In Blink / WebKit, the scrollable area seems like a property of the layer / layout object, and looking at Blink's implementation of scrollbar-gutter: force, at the very least this seems to affect various CSSOM methods like scrollWidth etc. It also forces layerization, though I don't know what side effects does that have in practice, seems it might affect paint order (as it behaves as if the element was relatively-positioned / created its own stacking context). So I still think it applying to non-scrollable boxes is a bad idea.

[felipeerias]

@emilio:

If I remember correctly, force elements get their own layer in Chromium simply because a PaintLayerScrollableArea is used to calculate the thickness of the element's hypothetical scrollbars. This is only strictly necessary to support custom scrollbars, otherwise it would be enough to query the current scrollbar theme.

(One advantage of supporting custom scrollbars is that they make it possible to write accurate and portable web tests for scrollbar-gutter, because their thickness can be specified explicitly)

A better implementation would reduce the number of layers to those strictly needed, thanks for pointing it out.

[emilio]

@felipeerias I find it a bit hard to believe that doesn't affect painting order in other unexpected ways, but I don't have the time to check right now.

[felipeerias]

@emilio My point was just that it is an implementation side effect of how Chromium calculates custom scrollbars, not something mandated by the spec.