Re: [csswg-drafts] [css-overflow-4] scrollbar-gutter is too complex (#4674)

## force:

`force` itself doesn't force the creation of gutters with overlay scrollbars (although it can be used together with `always`, which does). It forces the creation of gutters even if `overflow` is `visible` (or `clip`) if there would be gutters with the other values of `overflow`. So `scrollbar-gutter: stable force` would add gutters to `overflow:visible` elements if the UA uses classic scrollbars, and not if it uses overlay scrollbars. `scrollbar-gutter: always force` does add gutters to every element 

The use case was being able to reserve the same amount of space on the edges of an element that is adjacent to a stroller as is being reserved in the stroller itself, so that things would visually line up. The same effect could be achieved by adding padding for classic scrollbars and none for overlay scrollbars, but there is no reliable way for authors to know if they should be adding that padding, and if so how much.

A concrete example that was given was Gmail (I believe this was raised by Googlers, though I cannot remember for sure), and it's attempt to line up the controls in the toolbar above the list of mails with those in the list of mails. Here are two screenshots from my system (macOS with Firefox), one with classic scrollbars turned on (at the OS level), where Gmail correctly guesses how much padding it should be adding to the toolbar above the list, and one with overlay scrollbars turned off, where Gmail incorrectly adds padding, throwing things out of alignment (orange dotted line added manually to highlight what I'm talking about).

<img width="335" alt="classic" src="https://user-images.githubusercontent.com/113268/72501818-3506ea80-387b-11ea-84fa-f6fb1ded1d64.png">
<img width="314" alt="overlay" src="https://user-images.githubusercontent.com/113268/72501821-3801db00-387b-11ea-84b0-d1e440883bd3.png">



## Always:

Always does reserve space for a gutter even on browsers with overlay scrollbars.

This is for cases when authors find the overlap between the overlay scrollbar and the content to be problematic. If the scrollbar ends up being over decorative elements or empty space, it's ok, but if it ends up over text, it can hinder readability, and if over interactive elements, it can get in the way of trying to click those. Overlay scrollbars generally disappear or shrink (or both) when not used, so if the user waits a bit, the content will eventually no longer be obscured, and can be read or interacted with, but this can be annoying.

For instance, something like https://jsbin.com/bulidiv/edit?html,css,output  is really annoying to use in a browser with overlay scrollbars. You could add padding to get around that, but (1) how much padding is enough to avoid the overlay scrollbars?, and (2) that padding isn't needed in case of classic scrollbars, so you have to detect that too and remove the padding if you don't want to waste space.

[Here's an example at stackoverflow](https://stackoverflow.com/questions/439553/how-to-prevent-scrollbars-from-overlapping-the-content) of someone trying to deal with this situation.

----

Anyway, that's what these values are for, and they can be combined because these two use cases aren't exclusive (e.g. https://jsbin.com/kafoyuw/edit?html,css,output).

I think It may be useful to add examples to the spec along the lines of the things I showed here, to help readers understand what this is for.

> It is not clear how much space should be reserved.

The spec isn't clear about that, but the intention is that you'd reserve enough space for the overlay scrollbar to fit into when it is displayed. If it has multiple states of varying sizes (on macOS it gets bigger when you hover it), you'd size it to the largest one.

I'm happy to add that clarification.


-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4674#issuecomment-575027040 using your GitHub account

Received on Thursday, 16 January 2020 07:49:18 UTC