7 ms·

New CSS units that account for mobile viewports with dynamic toolbars

59 points by robust-cactus 4y ago

robust-cactus 4y ago
So many options when all I ever wanted was 100dvh
- techdragon 4y ago
  Honestly most of us probably just wanted 100dvh from the start... the idea that the viewport was "fixed" was less than ideal situation.
  - panzerboiler 4y ago
    Also 100dvh is less than ideal, since it snaps between 100svh and 100lvh when the browser's chrome contracts/expands (at least on Safari. I would like to know how google did implement it in Chrome on android). The reflow that this generates is probably even worse than just having the bottom part of the viewport clipped.
    - warning26 4y ago
      The space between is why dvh would be preferable; with this whole vmin/vmax/etc design, you’re setting brittle rules with specific parameters. With dvh it would all just work, and would even match whatever animation the browser used to transition between heights.
      - panzerboiler 4y ago
        In Safari there is no transition. The viewport height snaps between svh and lvh at the end of the browser's chrome collapse/expand animation. I don't have an android phone to check the Chrome's implementation, but I imagine it working in the same way, since animating the heights of potentially all the elements in the page can not be done in an efficient way by the browsers, and having a stuttery scroll as soon as you start scrolling a web page would not be a great user experience.
    - deleted 4y ago
      [deleted]
    - notpushkin 4y ago
      For most use cases, I think something along the lines of this would do the trick: /* * Show the element full height but make sure content * fits the “small” viewport with the toolbars visible. */ .full-blend { height: 100lvh; padding-block: calc((100lvh - 100svh) / 2 + 1em); }
- dmitriid 4y ago
  A year ago I skimmed through the spec and counted ~40 distance units in CSS (12 font units, 18 viewport units, 7 absolute distance units if I counted correctly). As you'd expect, none of them do what you'd really want them to do.
  - seydor 4y ago
    12 more now apparently
  - a9h74j 4y ago
    Off topic, but analogous: About a year ago, the last time I checked the Wikipedia page on energy use, I counted IIRC 10-20 different units being referenced. It is almost as if people were working to prevent uniform understanding and intuition.
  - bryanrasmussen 4y ago
    so actually XKCD is wrong https://xkcd.com/927/ https://xkcd.com/927/ standards proliferate because they're bad not because we need to unify standards under one master standard!
  - martin_a 4y ago
    I was just thinking about how many units for measurements are there in CSS. Thanks for providing the answer.
tobr 4y ago
> Celebration > This web feature is now available in all three browser engines! Lament There are only three browser engines.
- the_gipsy 4y ago
  And only one on iOS.
  - interactivecode 4y ago
    Is webkit on android? So two on android?
    - girvo 4y ago
      Does Firefox still exist and run their engine on Android?
      - frabert 4y ago
        Yes and it's quite good
        girvo 4y ago
        Nice! I loved using it when I was using Android regularly.
- dbbk 4y ago
  How many would you want? 10?
langsoul-com 4y ago
I think the most annoying thing about responsive is how bloody manual it all is. Small, medium, large font sizes. Different widths, heights and all that jazz. Cant 100% vh or vw just recalculate based on screen elements?
- frankzander 4y ago
  Good point ... at the end it's what you expect from vh ... just make it work without 10 different distinctions you'll never use in your life.
- danbruc 4y ago
  It first I would also have expected vh and vw to do this, i.e. do what dvh and dvw now do. And I think on purely theoretical grounds that would be the correct behavior, after all the view port dimensions do actually change. Well, unless you think of those dynamic elements as overlays in front of the view port. But what would be the implications? Every time some of those dynamic elements appear, everything based on the view port dimensions would also change in size. There are certainly cases where this is exactly what you want but I guess more commonly you would not want to have things change. There is a real difference between changing the size of your browser window where you want things to adapt and temporarily showing some additional user interface where you do not want everything to move around immediately. This seems actually to suggest that those dynamic elements should be overlays and not change the view port size, but I guess only if one focuses on this single issue. If done as overlays, then you could never see the very top or bottom of a page while those dynamic elements are visible which is not good eitehr.
- postalrat 4y ago
  What would 100% vh mean if the user pinch zooms in? Or if the virtual keyboard is up? There always seems to be some edge cases.
CGamesPlay 4y ago
The missing piece from these seems to be how you use them? When the page loads, is the viewport small or large? How does the CSS know?
- kijin 4y ago
  The browser knows. The browser interprets your CSS. The browser giveth, the browser taketh, you are not supposed to care. :)
seydor 4y ago
it s so funny how CSS people did not think before providing a 'solution' that fails the most useful use case, 100% height.
- azangru 4y ago
  100% of what? If you start by applying it to the topmost element, and then through the tree of the children, then it will work.
int_19h 4y ago
"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." Kind of amazing that this is literally the unit meant to solve such problems, and yet it doesn't. And the GitHub discussion seems to imply that it's mostly down to what the existing browsers did? https://github.com/w3c/csswg-drafts/issues/1766 https://github.com/w3c/csswg-drafts/issues/1766
- Ennea 4y ago
  I think one could argue (as many already have) that the purpose of the viewport units is not to solve scrollbar related problems. You can give your <body> element a width of 100% and it will fill all the viewport's space without the scrollbar. 100vw, in contrast, will add the scrollbar's width to this. Having these two be different can be quite beneficial, too.
  - chrismorgan 4y ago
    Such an argument is not useful, because no one wants viewport units that include the document scrollbars. Only with great difficulty can I imagine a valid use case for such units (and the recent CSS property scrollbar-gutter is a better solution for almost all remaining theoretical applications) and don’t believe I have encountered even a single instance in the wild.
  - asddubs 4y ago
    actually the 100% thing only works if you also apply it to the html element too (I believe). and that's kind of the problem, 100% refers to the height of the parent. so if you want to have an element that isn't the body fill up at least the entire viewport, you have to apply this to every parent element as well, which can be very annoying depending on the situation. of course what you end up doing is just using 100vh anyway, since you never want there to be a horizontal scrollbar anyway
- chrismorgan 4y ago
  “This is per specification.” is an awful cop-out. It’s something where there was a tolerable workaround, but it was ripped out because only Firefox ever implemented it and no one else wanted to. Even though the viewport units are fundamentally completely wrong on almost all documents without it, so that it’s basically impossible to use them correctly. And then they continued to completely ignore this in the new units, only caring about the mobile issues. Perhaps more relevant now is https://github.com/w3c/csswg-drafts/issues/6026 https://github.com/w3c/csswg-drafts/issues/6026 (loosely about bringing something back). The scrollbar-gutter suggestion would be fairly decent, mitigating the minor ugliness of overflow: scroll if the document isn’t long.
kijin 4y ago
Still no standard to reliably detect when a virtual keyboard is covering half the viewport. And virtual keyboards have been around for much longer than dynamic toolbars on mobiles browsers!
- b34r 4y ago
  window.visualViewport is the only API I’ve found that’s consistently correct
deleted 4y ago
[deleted]
dphnx 4y ago
Why oh why do they have to be three letter acronymns? I’m sure it’s fine if you’re immersed in front-end web development and have memorised the nuances of each unit, but as a back-end developer with a good working knowledge of CSS but for whom it isn’t my focus, I just know I’m going to have to constantly look these up every time I come across them.
- notpushkin 4y ago
  {Small, large, dynamic} viewport {width, height} – seems pretty obvious to me. Any alternatives?
andix 4y ago
Not confusing at all... /s
Yuyudo_Comiketo 4y ago
No thanks, I'll rather wait for CSS5 to thoroughly enjoy my hvlhlvh and t23ccwsvh units (held vertically in left hand large viewport height and tilted 23 degrees counter-clockwise small viewport height)
KrishnaAnaril 4y ago
This new unit is more significant on mobile browsers and as of now only firefox support it. I've verified it myself. Ref: https://caniuse.com/?search=dvh https://caniuse.com/?search=dvh

59 points by robust-cactus 4y ago

robust-cactus 4y ago

So many options when all I ever wanted was 100dvh

techdragon 4y ago
Honestly most of us probably just wanted 100dvh from the start... the idea that the viewport was "fixed" was less than ideal situation.
- panzerboiler 4y ago
  Also 100dvh is less than ideal, since it snaps between 100svh and 100lvh when the browser's chrome contracts/expands (at least on Safari. I would like to know how google did implement it in Chrome on android). The reflow that this generates is probably even worse than just having the bottom part of the viewport clipped.
  - warning26 4y ago
    The space between is why dvh would be preferable; with this whole vmin/vmax/etc design, you’re setting brittle rules with specific parameters. With dvh it would all just work, and would even match whatever animation the browser used to transition between heights.
    - panzerboiler 4y ago
      In Safari there is no transition. The viewport height snaps between svh and lvh at the end of the browser's chrome collapse/expand animation. I don't have an android phone to check the Chrome's implementation, but I imagine it working in the same way, since animating the heights of potentially all the elements in the page can not be done in an efficient way by the browsers, and having a stuttery scroll as soon as you start scrolling a web page would not be a great user experience.
  - deleted 4y ago
    [deleted]
  - notpushkin 4y ago
    For most use cases, I think something along the lines of this would do the trick: /* * Show the element full height but make sure content * fits the “small” viewport with the toolbars visible. */ .full-blend { height: 100lvh; padding-block: calc((100lvh - 100svh) / 2 + 1em); }
dmitriid 4y ago
A year ago I skimmed through the spec and counted ~40 distance units in CSS (12 font units, 18 viewport units, 7 absolute distance units if I counted correctly). As you'd expect, none of them do what you'd really want them to do.
- seydor 4y ago
  12 more now apparently
- a9h74j 4y ago
  Off topic, but analogous: About a year ago, the last time I checked the Wikipedia page on energy use, I counted IIRC 10-20 different units being referenced. It is almost as if people were working to prevent uniform understanding and intuition.
- bryanrasmussen 4y ago
  so actually XKCD is wrong https://xkcd.com/927/ https://xkcd.com/927/ standards proliferate because they're bad not because we need to unify standards under one master standard!
- martin_a 4y ago
  I was just thinking about how many units for measurements are there in CSS. Thanks for providing the answer.

tobr 4y ago

> Celebration > This web feature is now available in all three browser engines! Lament There are only three browser engines.

the_gipsy 4y ago
And only one on iOS.
- interactivecode 4y ago
  Is webkit on android? So two on android?
  - girvo 4y ago
    Does Firefox still exist and run their engine on Android?
    - frabert 4y ago
      Yes and it's quite good
      - girvo 4y ago
        Nice! I loved using it when I was using Android regularly.
dbbk 4y ago
How many would you want? 10?

langsoul-com 4y ago

I think the most annoying thing about responsive is how bloody manual it all is. Small, medium, large font sizes. Different widths, heights and all that jazz. Cant 100% vh or vw just recalculate based on screen elements?

frankzander 4y ago
Good point ... at the end it's what you expect from vh ... just make it work without 10 different distinctions you'll never use in your life.
danbruc 4y ago
It first I would also have expected vh and vw to do this, i.e. do what dvh and dvw now do. And I think on purely theoretical grounds that would be the correct behavior, after all the view port dimensions do actually change. Well, unless you think of those dynamic elements as overlays in front of the view port. But what would be the implications? Every time some of those dynamic elements appear, everything based on the view port dimensions would also change in size. There are certainly cases where this is exactly what you want but I guess more commonly you would not want to have things change. There is a real difference between changing the size of your browser window where you want things to adapt and temporarily showing some additional user interface where you do not want everything to move around immediately. This seems actually to suggest that those dynamic elements should be overlays and not change the view port size, but I guess only if one focuses on this single issue. If done as overlays, then you could never see the very top or bottom of a page while those dynamic elements are visible which is not good eitehr.
postalrat 4y ago
What would 100% vh mean if the user pinch zooms in? Or if the virtual keyboard is up? There always seems to be some edge cases.

CGamesPlay 4y ago

The missing piece from these seems to be how you use them? When the page loads, is the viewport small or large? How does the CSS know?

kijin 4y ago
The browser knows. The browser interprets your CSS. The browser giveth, the browser taketh, you are not supposed to care. :)

seydor 4y ago

it s so funny how CSS people did not think before providing a 'solution' that fails the most useful use case, 100% height.

azangru 4y ago
100% of what? If you start by applying it to the topmost element, and then through the tree of the children, then it will work.

int_19h 4y ago

"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." Kind of amazing that this is literally the unit meant to solve such problems, and yet it doesn't. And the GitHub discussion seems to imply that it's mostly down to what the existing browsers did? https://github.com/w3c/csswg-drafts/issues/1766 https://github.com/w3c/csswg-drafts/issues/1766

Ennea 4y ago
I think one could argue (as many already have) that the purpose of the viewport units is not to solve scrollbar related problems. You can give your <body> element a width of 100% and it will fill all the viewport's space without the scrollbar. 100vw, in contrast, will add the scrollbar's width to this. Having these two be different can be quite beneficial, too.
- chrismorgan 4y ago
  Such an argument is not useful, because no one wants viewport units that include the document scrollbars. Only with great difficulty can I imagine a valid use case for such units (and the recent CSS property scrollbar-gutter is a better solution for almost all remaining theoretical applications) and don’t believe I have encountered even a single instance in the wild.
- asddubs 4y ago
  actually the 100% thing only works if you also apply it to the html element too (I believe). and that's kind of the problem, 100% refers to the height of the parent. so if you want to have an element that isn't the body fill up at least the entire viewport, you have to apply this to every parent element as well, which can be very annoying depending on the situation. of course what you end up doing is just using 100vh anyway, since you never want there to be a horizontal scrollbar anyway
chrismorgan 4y ago
“This is per specification.” is an awful cop-out. It’s something where there was a tolerable workaround, but it was ripped out because only Firefox ever implemented it and no one else wanted to. Even though the viewport units are fundamentally completely wrong on almost all documents without it, so that it’s basically impossible to use them correctly. And then they continued to completely ignore this in the new units, only caring about the mobile issues. Perhaps more relevant now is https://github.com/w3c/csswg-drafts/issues/6026 https://github.com/w3c/csswg-drafts/issues/6026 (loosely about bringing something back). The scrollbar-gutter suggestion would be fairly decent, mitigating the minor ugliness of overflow: scroll if the document isn’t long.

kijin 4y ago

Still no standard to reliably detect when a virtual keyboard is covering half the viewport. And virtual keyboards have been around for much longer than dynamic toolbars on mobiles browsers!

b34r 4y ago
window.visualViewport is the only API I’ve found that’s consistently correct

deleted 4y ago

[deleted]

dphnx 4y ago

Why oh why do they have to be three letter acronymns? I’m sure it’s fine if you’re immersed in front-end web development and have memorised the nuances of each unit, but as a back-end developer with a good working knowledge of CSS but for whom it isn’t my focus, I just know I’m going to have to constantly look these up every time I come across them.

notpushkin 4y ago
{Small, large, dynamic} viewport {width, height} – seems pretty obvious to me. Any alternatives?

andix 4y ago

Not confusing at all... /s

Yuyudo_Comiketo 4y ago

No thanks, I'll rather wait for CSS5 to thoroughly enjoy my hvlhlvh and t23ccwsvh units (held vertically in left hand large viewport height and tilted 23 degrees counter-clockwise small viewport height)

KrishnaAnaril 4y ago

This new unit is more significant on mobile browsers and as of now only firefox support it. I've verified it myself. Ref: https://caniuse.com/?search=dvh https://caniuse.com/?search=dvh