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.
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.
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.
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);
}
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.
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.
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.
"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?
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.
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.
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
“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 (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.
vh was also invented to solve the height problem and it didnt. The current workaround still involves javascript! And dvw doesnt even solve the scrollbar problems so , javascript again.
There s so much going wrong with CSS through the years (cough, grid) that one wonders if it's being deliberately sabotaged. But most likely it's suffering from FOMOitis where , every weekly design trend must make its way into CSS.
Or maybe at some point Chrome developers will get fed up and say f'it and invent a new simple pixel level language to do whatever you want.
> vh was also invented to solve the height problem and it didnt. The current workaround still involves javascript!
Does it? `min-height: stretch` (expanded into `min-height: -webkit-fill-available` by autoprefixer) plus a `@supports (min-height:-moz-available)` workaround for FF seems to solve the problem, however inconvenient. That's what I've always used anyway.
i find it terrible design that breaks html as a language (that s meant to be readable). a bunch divs positioned arbitrarily via css is much less intuitive than <tables> where you can move blocks of markup to redesign geometrically . It's such a simpler mental model , and a set of <grid> elements would suffice. Changing layout with css grid involves changing multiple classes and is atrocious. Then there is the cryptic syntax where somehow "1 fraction" = "fill the rest of the space with it". I can hardly understand the motivation behind the grid design. Using tables is still much more pleasant, but modern browsers dislike table layouts and render them horribly.
the main problem with tables (besides render speed) is that it's very hard to prevent them being stretched wide by long contiguous words (like aaaaaaaaaaaaaaaaaa...) and images, and the usual ways to prevent those things don't work right in them. also there's no css rules for rowspan/colspan
I find it far easier to change things with grid than with tables. I think you might want to check named grid-templates if changing things currently requires changing classes.
> a bunch divs positioned arbitrarily via css is much less intuitive than <tables> where you can move blocks of markup to redesign geometrically <...> Using tables is still much more pleasant, but modern browsers dislike table layouts and render them horribly.
With html being a semantic markup language, tables should appropriately be used for tabular data. Grids are addressing a layout concern, in which you want to position stuff on your page just so. With grids, you can easily change the arrangement of your elements within a grid at different screen sizes, or opt out of the grid altogether. With html table markup, that would not be not possible.
> Kind of amazing that this is literally the unit meant to solve such problems, and yet it doesn't.
I thought the problem this was literally meant to solve was the ambiguity about what a viewport is on mobile browsers with various browser ui elements (address bar, keyboard) taking up space.
Isn't the problem with scrollbars one that it is easy to get into edge cases that result in infinite loops if the gutter space isn't stable?
The point is that scrollbars also affect what the viewport, meaningfully defined, is.
Getting into infinite loops is a possibility with any non-trivial layout engine if you implement it in certain ways. Per GitHub discussion, though, there is a known algorithm to handle it; the problem is that only Firefox implemented it, and even that as an experiment.
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!
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.
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)
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
53 comments
[ 2.9 ms ] story [ 113 ms ] threadAs you'd expect, none of them do what you'd really want them to do.
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.
standards proliferate because they're bad not because we need to unify standards under one master standard!
> This web feature is now available in all three browser engines!
Lament
There are only three browser engines.
Small, medium, large font sizes. Different widths, heights and all that jazz.
Cant 100% vh or vw just recalculate based on screen elements?
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.
If you start by applying it to the topmost element, and then through the tree of the children, then it will work.
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
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 (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.
There s so much going wrong with CSS through the years (cough, grid) that one wonders if it's being deliberately sabotaged. But most likely it's suffering from FOMOitis where , every weekly design trend must make its way into CSS.
Or maybe at some point Chrome developers will get fed up and say f'it and invent a new simple pixel level language to do whatever you want.
Does it? `min-height: stretch` (expanded into `min-height: -webkit-fill-available` by autoprefixer) plus a `@supports (min-height:-moz-available)` workaround for FF seems to solve the problem, however inconvenient. That's what I've always used anyway.
[1] https://caniuse.com/mdn-css_properties_min-height_stretch
What's wrong with grid?
Yeah that's what i m talking about. Someone has been racist to tables
With html being a semantic markup language, tables should appropriately be used for tabular data. Grids are addressing a layout concern, in which you want to position stuff on your page just so. With grids, you can easily change the arrangement of your elements within a grid at different screen sizes, or opt out of the grid altogether. With html table markup, that would not be not possible.
I thought the problem this was literally meant to solve was the ambiguity about what a viewport is on mobile browsers with various browser ui elements (address bar, keyboard) taking up space.
Isn't the problem with scrollbars one that it is easy to get into edge cases that result in infinite loops if the gutter space isn't stable?
Getting into infinite loops is a possibility with any non-trivial layout engine if you implement it in certain ways. Per GitHub discussion, though, there is a known algorithm to handle it; the problem is that only Firefox implemented it, and even that as an experiment.