Open emilio opened 3 years ago
Neither does overflow: visible
, but we have it take effect there, too.
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.
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.
I still think it's wrong. How does it affect inline elements? Svg?
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
).
What's the use case for applying this property on non-scrollable boxes?
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.
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
.
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.
@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.
@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.
@emilio My point was just that it is an implementation side effect of how Chromium calculates custom scrollbars, not something mandated by the spec.
FYI, the issue where force
was creating unneeded layers in Chromium has already been fixed:
https://chromium.googlesource.com/chromium/src/+/2402abcb4c84404546998aa55a85cb711ae50eec
@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.
In Blink/WebKit, it is true that allocating a PaintLayer (RenderLayer in WebKit) affects paint order. But that's just an implementation mistake (a big one, as it turns out! In Blink we've been working on fixing it for years now.) that should be fixed. In any case, the commit Felipe mentioned above avoids this problem in the case of scrollbar-gutter
, and any other effect is also a bug. If an element has overflow:clip
and scrollbar-gutter
, then paint order should not be affected. Implementations can avoid creating any of these side-effect-causing data structures by just treating scrollbar-gutter
as another form of margin.
Also, to re-iterate the use cases already mentioned above:
I don't know how common (2) is, but I think (1) is common.
The CSS Working Group just discussed [css-overflow] scrollbar-gutter should not do anything for non-scrollable boxes
.
Restricting to only scrollable boxes is ok by me, in order to unblock consensus on the most important use case for scrollbar-gutter
. See my comment here.
Changing tags for this and #4674 in favor of a breakout session
https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property:
Why?
overflow: clip
doesn't create an scrolling box, so it seems weirdscrollbar-gutter
somehow affects this.