3 ms·

> New viewport units These new viewport units frustrate me immensely, because they have completely ignored the longstanding complete brokenness of viewport uni

> New viewport units These new viewport units frustrate me immensely, because they have completely ignored the longstanding complete brokenness of viewport units on platforms that don’t use zero-layout-width overlay scrollbars (which currently means pretty much all desktop platforms except macOS by default, and even there it’s at least easily possible to turn off overlay scrollbars). Basically, viewport units are always the wrong thing if there might be scrollbars: they’re broken by design. Instead they’ve fixed the problem with inconsistency of interpretation of viewport height units on mobile browsers, which was, generally speaking, not something that was broken in the same way as the desktop situation, and there were simple (if non-obvious) practical workarounds for the most likely thing people wanted anyway. So yeah, the new viewport units are worthwhile for what they improve in mobile browsers, but I’m disgruntled that they’re being presented as fixing viewport unit situation when the people involved have continued to basically ignore what I perceive as the real and most significant problem with viewport units, which has been an issue from the very start in all browsers except Firefox, which used to have a tolerable workaround (essentially: `body { overflow-y: scroll }` would make vw exclude the scrollbar) until it was ripped out of the spec and Firefox because no one else was interested in implementing it for some reason. In short: the new viewport units are still fundamentally broken by design, only in a way that doesn’t affect most mobile platforms or the default macOS configuration.

spartanatreyu 5y ago
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.
thepra 5y ago
I'm all in for this units, finally on mobile that navigation bar would not screw up webapps

spartanatreyu 5y ago

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.

thepra 5y ago

I'm all in for this units, finally on mobile that navigation bar would not screw up webapps