Avoid 100vh on Mobile Web

I recently had to deal with this issue, you&#x27;d think this had to be solved by now.<p>So as suggested on SO: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;55003985" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;55003985</a>,<p><pre><code> min-height: -webkit-fill-available; </code></pre> 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.

Here is an article from 2015 about the same problem but with more context and examples:<p><a href="https:&#x2F;&#x2F;nicolas-hoizey.com&#x2F;2015&#x2F;02&#x2F;viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html" rel="nofollow">https:&#x2F;&#x2F;nicolas-hoizey.com&#x2F;2015&#x2F;02&#x2F;viewport-height-is-taller...</a>

The reason they do it is to avoid the redraw when hiding&#x2F;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&#x27;m sure performs worse and was a pain to implement.

An easy solution is to add a height transition:<p><pre><code> .full-height { min-height: 100vh; transition: height 1000s steps(1); } </code></pre> This will let you maintain the initial height with the address bar excluded, and won&#x27;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&#x27;s one of the reasons bloated frameworks like bootstrap become popular and all users pay the price.

You can fall back to the oldskool way of setting the height of the parent nodes to 100%:<p><pre><code> html, body, .full-height { height:100% } </code></pre> I guess this is exactly the thing the viewport units were designed to overcome, but at least it&#x27;s a pure css solution.

Does this apply to all browsers on mobile?<p>Because I&#x27;ve never experienced this in Firefox on android

Per [1] it sounds like it should be usable with &quot;position: fixed&quot;. Though I can&#x27;t test it right now.<p>There&#x27;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).<p>[1] <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;updates&#x2F;2016&#x2F;12&#x2F;url-bar-resizing" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;updates&#x2F;2016&#x2F;12&#x2F;url-bar-re...</a> [2] <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=428132" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=428132</a> [3] <a href="https:&#x2F;&#x2F;github.com&#x2F;bokand&#x2F;URLBarSizing" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bokand&#x2F;URLBarSizing</a>

Using JS over CSS for sizing elements rarely is a &#x27;better solution&#x27;, mostly because of flashes of unstyled content - <i>especially</i> on mobile where it might take longer for the JS to fully initialise.<p>Like other comments on here say, just use height: 100% instead.

And no way to test it with the address bar visible in the Chrome emulator. So it&#x27;s all nice and dandy until you actually load the site on a mobile device.

Mobile html dev feels like it’s taken a step back lately. With vh not being the true viewport height and with user-scalable no longer being respected, it’s become very difficult to build advanced apps for the mobile web. A lot of it feels like reactionary changes due to abuse by devs of these features which lead to bad UX, but it comes at the expense of allowing richer apps.

There&#x27;s a better solution for 100vh on mobile by csstricks - <a href="https:&#x2F;&#x2F;css-tricks.com&#x2F;the-trick-to-viewport-units-on-mobile&#x2F;" rel="nofollow">https:&#x2F;&#x2F;css-tricks.com&#x2F;the-trick-to-viewport-units-on-mobile...</a>

I recommend just avoiding viewport units altogether; this isn’t the only problem with them. The fact that they <i>include</i> scrollbars on the document element means that 100vw and 100vh are just <i>never</i> what you desire, if scrolling can occur.

use the correct feature for your use case. for a dynamic background behind a scrolling page use 100vh if the size depends on the height otherwise the background will do this strange shrink and grow thing as the UI changes size

This issue has been reported at least 4 years ago to Webkit: <a href="https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=141832" rel="nofollow">https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=141832</a>

I&#x27;ve always used 100vh (or just over) to ensure my footer is always at the bottom of the page. I assume this is fine still?

As one of the comments below the post mentions, `html, body {height: 100%}` should work just fine.

stackoverflow discussion and more Infos on this: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;37112218&#x2F;1216595" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;37112218&#x2F;1216595</a>

I just wish browsers would follow standards instead of having half dozen frail workarounds that have to be reworked at each drop of new browser versions