5 ms·

Dear Santa, I would like to have CSS units of viewport size that automatically subtract the scrollbar width. A cross between 100% (which discounts scrollbars

Dear Santa, I would like to have CSS units of viewport size that automatically subtract the scrollbar width. A cross between 100% (which discounts scrollbars but is unaware of viewport) and 100vw (which is aware of the viewport but does not exclude scrollbars). I understand that such a unit of measurement means overcoming infinite loops caused by edge cases. This is where your elves come in.

deleted 4y ago
[deleted]
chrismorgan 4y ago
> means overcoming infinite loops caused by edge cases It doesn’t, really, if you instead just commit to reserving space for the scrollbars. And this indeed was how viewport units were initially specified a decade ago, and implemented in Firefox: write `html { overflow-y: scroll }` or similar, and vw is now actually what 100% of users want (seriously, there are exactly zero valid use cases for the current behaviour, it’s wrong every single time—just very occasionally useful despite its unknowable-in-pure-CSS rate of error). Unfortunately, no one else implemented it or was interested in doing so (even though this was the only hope of making viewport units correct for >99% of web pages—and remember this was before flex, too, so it was much more common to need correct viewport units) and they ended up ripping it out of the spec and Firefox a few years later. And it looks like the only hope of ever getting sane viewport units is doing much the same once again, but more likely just with scrollbar-gutter this time. But having monitored relevant issues on the CSSWG bug tracker for years, I’m not holding my breath for any sort of fix. No, it’s pretty clear that no browser makers are much interested in fixing ancient design bugs in scroll bars that take space.
- blowski 4y ago
  Assuming browser developers are not insane or incompetent psychopaths, why do you think they’ve done it this way?
alberth 4y ago
calc(100vw - (100vw - 100%)) Does above not work? https://stackoverflow.com/questions/33606565/is-it-possible-to-calculate-the-viewport-width-vw-without-scrollbar https://stackoverflow.com/questions/33606565/is-it-possible-...
- chrismorgan 4y ago
  No: (a) it only works on elements whose parents are the full viewport width, such as the body (simplifying the rules a little—there’s much finer nuance to the interpretation of percentages), and most of the places you might want viewport units aren’t suitable; and (b) that’s literally just a longwinded way of writing “100%”, because mathematics.
- anamexis 4y ago
  As a comment on that answer points out, 100vw - (100vw - 100%) = 100vw - 100vw + 100% = 100%
Someone1234 4y ago
On the face of it, the only thing I'd worry about is if scrollbars appear/disappear, and if that would cause the elements using this new unit to get resized up/down. Or to phase another way: If the scrollbar isn't currently rendered, is a hypothetical scrollbar still excluded or not? Since both ways you answer this question may make people unhappy.
- azangru 4y ago
  The most common problem that I see is that people (almost always writing their CSS on a Mac, because Macs, by default, would hide the consequences of this) assign a width of 100vw to their header, footer, or main section, as a result of which, the moment that the page content's height exceeds the viewport height, the page will show not just a vertical scrollbar, but a horizontal scrollbar as well, because now 100vw is greater than 100% of body width. The above is easily fixed; however, I have also seen designs like this one [0], where a team has painted itself into a corner by assigning max-width to the body element; yet also wanting to have hero elements inside of the body element that would break out of the confines of the body and span the whole width of the viewport. They tried to use 100vw for the hero, which resulted in the infamous horizontal scrollbar. (I have since learnt — from Josh Comeau, I think — that their design problem could have been cleanly solved by designing the layout with CSS grid) [0] - https://i.imgur.com/LNyJIAq.png https://i.imgur.com/LNyJIAq.png
c-smile 4y ago
> automatically subtract the scrollbar width Santa: "That is simply impossible with the default scrollbar model". You may have infinite loop in layout algorithm in cases when content is close to size of the viewport. 0) remove scrollbars 1) calculate VW; 2) do content layout; 3) if content exceeds viewport height, add v-scrollbar and goto 1 if it has not the scrollbar before; 4) if content does not exceed viewport height, remove v-scrollbar and goto 1 if it has it before; The only option is to use scrollbars that do not take space: normally scrollbar appears as thin semitransparent bar on top of content. And on mouse hover the real scrollbar appears , but again on top of content. Such scrollbars do not cause re-layout as you see and VW is a viewport width always. That's why in Sciter(https://sciter.com https://sciter.com) I've added overflow:scroll-indicator; That's exactly that non-taking-space-scrollbar.
- azangru 4y ago
  Dear Santa, Please consult the list of gifts you brought to us for Christmas before the last. You will find included in that list the scrollbar-gutter property. With scrollbar-gutter set to stable, you could safely skip steps 3 and 4 in your algorithm, thus avoiding the infinite loop. Would you please consider giving our wish a second thought?
  - c-smile 4y ago
    Why do you need to waste screen space for the gutter? Check your mobile devices that use such scroll indicators. We haven't heard any major complaints about them.
madeofpalk 4y ago
Do the new large/small/dynamic viewport units satisfy that need? https://css-tricks.com/the-large-small-and-dynamic-viewports/ https://css-tricks.com/the-large-small-and-dynamic-viewports...
- azangru 4y ago
  No, they address ui elements other than the scrollbars.
  - alberth 4y ago
    I don’t think that’s correct. I think VMIN solves the OP comment. “Unit vmin refers to the smallest dimension of the viewport. Just like is the case with unit vw, unit vmin needs recalculation to subtract the scrollbar from the viewport width. https://www.terluinwebdesign.nl/en/css/incoming-20-new-css-viewport-units-svh-lvh-dvh-svw-lvw-dvw/ https://www.terluinwebdesign.nl/en/css/incoming-20-new-css-v...
    - azangru 4y ago
      From the article on the new viewport units, from the web.dev site maintained by Google[0]: "Caveats There‘s a few caveats to know about Viewport Units: - None of the viewport units take the size of scrollbars into account. On systems that have classic scrollbars enabled, an element sized to 100vw will therefore be a little bit too wide. This is as per specification." Notice that although the example in the above paragraph uses the well-known vw unit, the text explicitly says "none of the viewport units". [0] - https://web.dev/viewport-units/#caveats https://web.dev/viewport-units/#caveats
alberth 4y ago
scrollbar-gutter: stable Seems like someone else in this thread might have solved this problem. https://news.ycombinator.com/item?id=34116719 https://news.ycombinator.com/item?id=34116719 https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...

deleted 4y ago

[deleted]

chrismorgan 4y ago

> means overcoming infinite loops caused by edge cases It doesn’t, really, if you instead just commit to reserving space for the scrollbars. And this indeed was how viewport units were initially specified a decade ago, and implemented in Firefox: write `html { overflow-y: scroll }` or similar, and vw is now actually what 100% of users want (seriously, there are exactly zero valid use cases for the current behaviour, it’s wrong every single time—just very occasionally useful despite its unknowable-in-pure-CSS rate of error). Unfortunately, no one else implemented it or was interested in doing so (even though this was the only hope of making viewport units correct for >99% of web pages—and remember this was before flex, too, so it was much more common to need correct viewport units) and they ended up ripping it out of the spec and Firefox a few years later. And it looks like the only hope of ever getting sane viewport units is doing much the same once again, but more likely just with scrollbar-gutter this time. But having monitored relevant issues on the CSSWG bug tracker for years, I’m not holding my breath for any sort of fix. No, it’s pretty clear that no browser makers are much interested in fixing ancient design bugs in scroll bars that take space.

blowski 4y ago
Assuming browser developers are not insane or incompetent psychopaths, why do you think they’ve done it this way?

alberth 4y ago

calc(100vw - (100vw - 100%)) Does above not work? https://stackoverflow.com/questions/33606565/is-it-possible-to-calculate-the-viewport-width-vw-without-scrollbar https://stackoverflow.com/questions/33606565/is-it-possible-...

chrismorgan 4y ago
No: (a) it only works on elements whose parents are the full viewport width, such as the body (simplifying the rules a little—there’s much finer nuance to the interpretation of percentages), and most of the places you might want viewport units aren’t suitable; and (b) that’s literally just a longwinded way of writing “100%”, because mathematics.
anamexis 4y ago
As a comment on that answer points out, 100vw - (100vw - 100%) = 100vw - 100vw + 100% = 100%

Someone1234 4y ago

On the face of it, the only thing I'd worry about is if scrollbars appear/disappear, and if that would cause the elements using this new unit to get resized up/down. Or to phase another way: If the scrollbar isn't currently rendered, is a hypothetical scrollbar still excluded or not? Since both ways you answer this question may make people unhappy.

azangru 4y ago
The most common problem that I see is that people (almost always writing their CSS on a Mac, because Macs, by default, would hide the consequences of this) assign a width of 100vw to their header, footer, or main section, as a result of which, the moment that the page content's height exceeds the viewport height, the page will show not just a vertical scrollbar, but a horizontal scrollbar as well, because now 100vw is greater than 100% of body width. The above is easily fixed; however, I have also seen designs like this one [0], where a team has painted itself into a corner by assigning max-width to the body element; yet also wanting to have hero elements inside of the body element that would break out of the confines of the body and span the whole width of the viewport. They tried to use 100vw for the hero, which resulted in the infamous horizontal scrollbar. (I have since learnt — from Josh Comeau, I think — that their design problem could have been cleanly solved by designing the layout with CSS grid) [0] - https://i.imgur.com/LNyJIAq.png https://i.imgur.com/LNyJIAq.png

c-smile 4y ago

> automatically subtract the scrollbar width Santa: "That is simply impossible with the default scrollbar model". You may have infinite loop in layout algorithm in cases when content is close to size of the viewport. 0) remove scrollbars 1) calculate VW; 2) do content layout; 3) if content exceeds viewport height, add v-scrollbar and goto 1 if it has not the scrollbar before; 4) if content does not exceed viewport height, remove v-scrollbar and goto 1 if it has it before; The only option is to use scrollbars that do not take space: normally scrollbar appears as thin semitransparent bar on top of content. And on mouse hover the real scrollbar appears , but again on top of content. Such scrollbars do not cause re-layout as you see and VW is a viewport width always. That's why in Sciter(https://sciter.com https://sciter.com) I've added overflow:scroll-indicator; That's exactly that non-taking-space-scrollbar.

azangru 4y ago
Dear Santa, Please consult the list of gifts you brought to us for Christmas before the last. You will find included in that list the scrollbar-gutter property. With scrollbar-gutter set to stable, you could safely skip steps 3 and 4 in your algorithm, thus avoiding the infinite loop. Would you please consider giving our wish a second thought?
- c-smile 4y ago
  Why do you need to waste screen space for the gutter? Check your mobile devices that use such scroll indicators. We haven't heard any major complaints about them.

madeofpalk 4y ago

Do the new large/small/dynamic viewport units satisfy that need? https://css-tricks.com/the-large-small-and-dynamic-viewports/ https://css-tricks.com/the-large-small-and-dynamic-viewports...

azangru 4y ago
No, they address ui elements other than the scrollbars.
- alberth 4y ago
  I don’t think that’s correct. I think VMIN solves the OP comment. “Unit vmin refers to the smallest dimension of the viewport. Just like is the case with unit vw, unit vmin needs recalculation to subtract the scrollbar from the viewport width. https://www.terluinwebdesign.nl/en/css/incoming-20-new-css-viewport-units-svh-lvh-dvh-svw-lvw-dvw/ https://www.terluinwebdesign.nl/en/css/incoming-20-new-css-v...
  - azangru 4y ago
    From the article on the new viewport units, from the web.dev site maintained by Google[0]: "Caveats There‘s a few caveats to know about Viewport Units: - None of the viewport units take the size of scrollbars into account. On systems that have classic scrollbars enabled, an element sized to 100vw will therefore be a little bit too wide. This is as per specification." Notice that although the example in the above paragraph uses the well-known vw unit, the text explicitly says "none of the viewport units". [0] - https://web.dev/viewport-units/#caveats https://web.dev/viewport-units/#caveats

alberth 4y ago

scrollbar-gutter: stable Seems like someone else in this thread might have solved this problem. https://news.ycombinator.com/item?id=34116719 https://news.ycombinator.com/item?id=34116719 https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...