3 ms·

I believe this is what the scrollbar gutter proposal is supposed to fix: https://css-tricks.com/almanac/properties/s/scrollbar-gutter/ https://css-tricks.com/a

I believe this is what the scrollbar gutter proposal is supposed to fix: https://css-tricks.com/almanac/properties/s/scrollbar-gutter/ https://css-tricks.com/almanac/properties/s/scrollbar-gutter... Essentially, you can specify if a scrollbar is supposed to take up space or render overlaid on top of content. In the case that a scrollbar takes up space, you can specify if the other side should also have a matching amount of space taken up to keep content centered. If the above proposal passes (which it probably will do), then there is no more issue with the new viewport units.

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.

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.