works exactly as intended in Safari (mobile and desktop), but unfortunately breaks in desktop Chrome for me, so I ended up putting it in a media query for mobile only.
The reason they do it is to avoid the redraw when hiding/showing the address bar. If you use JavaScript you get that performance issue. Having been bit by this issue, I think chrome and Safari made the wrong decision. We worked around it with JavaScript, which I'm sure performs worse and was a pain to implement.
they made the right decision imo. vh units can be used for font-size. if you set font-size: 5vh; (5% of height) then as they shrank the browser chrome/address bar the size of the entire page and all word wrapping etc would change. that would be bad user experience. that's just one example of the unintended consequences of the mobile UI dynamically changing size under normal use.
Yep, having to add an event listener for that is really an awful idea.
I had a similar problem with mobile Chrome, you can add a media queue for that.
But we have a specification for a reason, if we started to add work around for every minor inconsistency...
This will let you maintain the initial height with the address bar excluded, and won't let it change when the bar disappears. Steps timing function is to avoid costly layout calculations.
This kind of exemplifies the problem with web development in general. 100vh would have been so intuitive if it worked correctly. This is why a lot of web devs hate CSS. One needs to remember so many hacks to get the webapps behave correctly! It's one of the reasons bloated frameworks like bootstrap become popular and all users pay the price.
If you have a site that's N screens high and you want to set the height of a div (i.e. an image) so it covers the whole landing area (what the user sees when the site loads) then this code won't help. You have to use vh
Firefox handles it differently than Chrome. In Firefox, the amount reflecting 100vh is changed while the address bar is hidden. So you always see the full 100vh, but the layout might change if for example the spacing is calculated based on the vh unit (or vmax in portrait mode, or vmin in landscape mode).
> the layout might change if for example the spacing is calculated based on the vh unit (or vmax in portrait mode, or vmin in landscape mode).
That sounds like a good thing, and pretty much the entire point of using viewport-relative units?
I'd certainly expect vh/vw-based layouts to change when I change the size of my viewport, whether by hiding and showing ancillary UI elements (e.g. sidebars or control bars of my browsers) or by manipulating the browser window directly.
Per [1] it sounds like it should be usable with "position: fixed". Though I can't test it right now.
There's some interesting (hopefully not outdated) discussion in the Chromium bug here [2][3] which helps explain why things the way they are (balancing several competing constraints).
So as suggested on SO: https://stackoverflow.com/a/55003985,
works exactly as intended in Safari (mobile and desktop), but unfortunately breaks in desktop Chrome for me, so I ended up putting it in a media query for mobile only.https://nicolas-hoizey.com/2015/02/viewport-height-is-taller...
I had a similar problem with mobile Chrome, you can add a media queue for that. But we have a specification for a reason, if we started to add work around for every minor inconsistency...
Increase to hours, days, or years as you feel appropriate for your audience. Unless the visitors spend days looking at the screen, they won't notice.
Deleted Comment
Because I've never experienced this in Firefox on android
That sounds like a good thing, and pretty much the entire point of using viewport-relative units?
I'd certainly expect vh/vw-based layouts to change when I change the size of my viewport, whether by hiding and showing ancillary UI elements (e.g. sidebars or control bars of my browsers) or by manipulating the browser window directly.
Deleted Comment
There's some interesting (hopefully not outdated) discussion in the Chromium bug here [2][3] which helps explain why things the way they are (balancing several competing constraints).
[1] https://developers.google.com/web/updates/2016/12/url-bar-re... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=428132 [3] https://github.com/bokand/URLBarSizing