- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Apr 2021 03:09:43 +0000
- To: public-css-archive@w3.org
> I propose that we remove always from the scrollbar-gutter spec, as it would require leaving space even in the presence of overlay scrollbars.
Yes, that is very much intentional, to solve the "interactive content underneath an overlay scrollbar" use case described in https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-787614795.
<details style=border:solid><summary>(summary of that use case for those who haven't read that thread)</summary>
The use case is when you have (small) interactive elements near the edge where the scrollbar would be. For instance, a basic todo list, with each line starting with some text and ending with a right-aligned checkbox. If you have a classic scrollbar, everything's fine, but if you have an overlay scrollbar, it could obscure the check boxes and make them hard to interact with.
This is fine:
This is not great:
Overlay Scrollbar are typically transient and disappear when not interacted with, so the checkboxes they cover are not impossible to use. But when the scrollbars are there they get in the way, and that makes for an awkward interaction. The author might try and solve the problem by adding some right padding, but (1) how much?, and (2) that padding isn't needed in the case of classic scrollbars. scrollbar-gutter: always does just the right thing in this case, yielding an identical result in the first case, but allowing for this with overlay scrollbars:
This is not necessarily always what you want, but some of the time it is.
<hr>
</details>
> Second, I propose we introduce an environment variable or measurement unit for the width of scrollbars, to handle the use case of making sure interactive content does not end up underneath an overlay scrollbar (see issue #5232). As @emilio has mentioned elsewhere, this will also resolve issue #6026.
* We would need two environment variables to solve this two use cases, not one:
* for the use case summarized above, we would need an env variable that is the width of the scrollbar when scrollbars are of the overlay kind, but 0 with classic scrollbars
* for #6026, we'd need the opposite: an env variable that is 0 when scrollbars are of the overlay kind, but the width of the scrollbar with classic scrollbars. This is also the one you'd need if you wanted to replace the `force` value as discussed in https://github.com/w3c/csswg-drafts/issues/4674#issuecomment-575027040
* You'd need a unit (well, two), not env variables, as due to the [scrollbar-width](https://drafts.csswg.org/css-scrollbars/#scrollbar-width) property, not all scrollbars in the page need to be the same width
* Possibly you'd need to double up the amount if units to 4, to account for the fact that scrollbars can end up on either side of the element (either due to bidi, or to something like https://github.com/w3c/csswg-drafts/issues/1293)
* Possibly, you'd need to double up yet again the amount of units to return the scrollbar width on the nearest scrolling ancestor rather than on the element itself, to replace the uses of the proposed `match-parent` value
If we could get away with a single env variable, it could possibly be a nicer solution. If we need a whole bunch of units, that feels a lot less attractive.
I've gone into more details about why I think units or env variables would not be a good solution in https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-648047604
--
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4674#issuecomment-820024418 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 April 2021 03:09:45 UTC