The CSS viewport unit situation is so frustrating. First they introduced vw and vh, and those did the obvious thing: reflect the viewport. Then mobile WebKit/Safari broke vh for many use cases, because they couldn't make the obvious behavior perform at 60fps in combination with their UI choices (the actual problem always remained vague: "looks like shit but we can't show you"). Instead these units started ignoring any browser chrome that could change size. This makes them useless for any purpose where the actual size of the viewport matters. Other browsers followed because Safari was not going to change.
Now, years later, the obvious behavior is re-introduced in the form of dvh. vh and vw are no longer recommended because their behavior regarding changing UI is unspecified.
The idea of a static viewport unit is not bad. It's useful for things that don't actually care about the viewport size, but just want to be somewhat responsive (font size). I don't think I've ever seen a situation where lvh vs svh matters, because the web developer has no say in browser UI behavior.
It's just sad how many hours have been wasted working around a problem only introduced because Apple couldn't deal with a small temporary framerate drop.
> First they introduced vw and vh, and those did the obvious thing: reflect the viewport.
Well… not the viewport you’d expect. They reflect the viewport including document scrollbars, which means that, if scrollbars are, say, 17px wide, then on a vertically-scrolling document with no margins, 100vw is equal to 100% of the body width plus 17px.
The result of this is that viewport units have always been fundamentally broken and incorrect in the main place people wanted to use them: 100vw will cause overflow if scrollbars take any space.
Then along comes this new generation of viewport units, fixing an artificial problem (as you say), and continuing to ignore the actual bug, because the browser makers don’t care much about non-overlay scrollbars any more, even though that’s still the considerable majority of non-mobile users, and supported even on those non-mobile platforms that default to overlay scrollbars. (Aside: I’m glad that even when Windows is heading in the direction of overlay scrollbars, they’re at least not hiding the thumb whenever possible like macOS and all mobile platforms do. Also I miss Ubuntu’s Ayatana overlay scrollbars from about a decade ago—a bit gimmicky, but they showed care in balancing considerations and generally worked very well.)
And perhaps the worst part of it all? The spec actually included a practical workaround (give the document `overflow-y: scroll` so there’s always a vertical scrollbar, and vw will exclude any space allocated to that scrollbar—and the same for overflow-x/vh), but only Firefox implemented it, and no one else wanted to, and so it was eventually removed from the spec and from Firefox.
I think we Moore'd past the iPhone's sluggishness running decent AS3 code around 2012 once Adobe got Flash Player iOS into beta... still didn't stop Apple from decimating a million lines of my code and destroying everyone's ability to play my games.
Now, years later, the obvious behavior is re-introduced in the form of dvh. vh and vw are no longer recommended because their behavior regarding changing UI is unspecified.
The idea of a static viewport unit is not bad. It's useful for things that don't actually care about the viewport size, but just want to be somewhat responsive (font size). I don't think I've ever seen a situation where lvh vs svh matters, because the web developer has no say in browser UI behavior.
It's just sad how many hours have been wasted working around a problem only introduced because Apple couldn't deal with a small temporary framerate drop.