"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."<p>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?<p><a href="https://github.com/w3c/csswg-drafts/issues/1766" rel="nofollow">https://github.com/w3c/csswg-drafts/issues/1766</a>
I think the most annoying thing about responsive is how bloody manual it all is.<p>Small, medium, large font sizes. Different widths, heights and all that jazz.<p>Cant 100% vh or vw just recalculate based on screen elements?
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!
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: <a href="https://caniuse.com/?search=dvh" rel="nofollow">https://caniuse.com/?search=dvh</a>
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.