We’ve got viewport units (e.g. vw, vh, vmin, vmax), and they are mostly pretty great. It’s cool to always have a unit available that is relative to the entire screen. But when you ask people what they want fixed up in CSS, viewport units are always on the list. The problem is that people use them to do things like position important buttons along the bottom of the screen on mobile devices. Do something like that wrong, it might cost you $8 million dollars.
What’s “wrong”? Well, assuming that 100vh is the visible/usable area in the viewport. Whaaaat? Isn’t that the point of those units? There are tricks like this and this, but that’s why people are unhappy. None of that is intuitive and huge mistakes are all too common. Even though Safari 15 is going to make this a little better, I’d say it’s still not particularly intuitive how you have to handle it.
Bramus Van Damme covers that the spec now includes some new values:
- The “Large Viewport”:
lvh/lvw/lvmin/lvmax - The “Small Viewport”:
svh/svw/svmin/svmax The “Baby Bear Viewport”- The “Dynamic Viewport”:
dvh/dvw/dvmin/dvmax
It seems to me the dynamic ones are the useful ones, because they will be intuitive: the units that represent the currently usable space, be it large or small.
The Dynamic Viewport is the viewport sized with *dynamic consideration of any UA interfaces*. It will automatically adjust itself in response to UA interface elements being shown or not: the value will be anything within the limits of
Bramus Van Damme, “The Large, Small, and Dynamic Viewports”100vh(maximum) and100svh(minimum).
