3 ms·
Concretely, https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-820026515 https://github.com/w3c/csswg-drafts/issues/6026#issuecomment... and https://g
by chrismorgan 5y ago
Concretely, https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-820026515 https://github.com/w3c/csswg-drafts/issues/6026#issuecomment... and https://github.com/w3c/csswg-drafts/issues/5254 https://github.com/w3c/csswg-drafts/issues/5254. My summary: a year and two ago, one guy (OK, an Invited Expert, so he is involved in matters and isn’t just a rando) suggested going back to what the spec used to have about `overflow: scroll` on the root, and adding scrollbar-gutter to the ways of activating that behaviour (which would be fair and reasonable), but no one else has really talked about it at all and there’s no movement—and, perplexingly, it doesn’t look to have actually been a motivating case of scrollbar-gutter.
Also scrollbar-gutter is a decidedly incomplete solution, only accounting for block axis overflow (thus inline axis size, vi, almost always equivalent to vw), and failing to handle edge-to-edge styling with classic scrollbars when scrollbars aren’t required. So you’re trading one broken thing for another only-slightly-less-broken thing. In order to be properly useful in the presence of things like full-width elements with background colours or images or whatever, it needs to be able to be paired with env(safe-area-inset-*) (though hopefully with logical unit names) so that in the absence of a scrollbar you can opt into drawing in the space reserved for it.