
Avoid 100vh on Mobile Web - chanind
https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html
======
chrenn
I recently had to deal with this issue, you'd think this had to be solved by
now.

So as suggested on SO:
[https://stackoverflow.com/a/55003985](https://stackoverflow.com/a/55003985),

    
    
        min-height: -webkit-fill-available;
    

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.

------
uallo
Here is an article from 2015 about the same problem but with more context and
examples:

[https://nicolas-hoizey.com/2015/02/viewport-height-is-
taller...](https://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-
the-visible-part-of-the-document-in-some-mobile-browsers.html)

------
eloff
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.

~~~
greggman2
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.

------
abdusco
An easy solution is to add a height transition:

    
    
        .full-height {
            min-height: 100vh;
            transition: height 1000s steps(1);
        }
    

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.

~~~
jannes
Wouldn't this change after 16m 40s?

~~~
wereHamster
Yes, that is true.

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.

------
pritambarhate
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.

------
tsar_nikolai
You can fall back to the oldskool way of setting the height of the parent
nodes to 100%:

    
    
      html, body, .full-height {
        height:100%
      }
    

I guess this is exactly the thing the viewport units were designed to
overcome, but at least it's a pure css solution.

~~~
macando
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_

~~~
dao-
Or you use position:fixed?

~~~
macando
And set the height to what? Using percentages means 100% relative to the
parent. What if the whole site is the parent and that site is 3 screens high?
I haven't found the way to make it work without relying on _vh_ or JavaScript.

~~~
jaxn
Set top: 0; bottom: 0

~~~
macando
Maybe we are talking about 2 different things. I want to stretch the image to
the bottom of the visible area not to the bottom of the site. If the height of
the parent is 100% and that parent is the site itself and it's 5000px high
(because the rest of the content made it that high) then setting the bottom to
0px will stretch the image's height to 5000px.

~~~
goblin89
> 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)

I believe “what the user sees when the site loads” is often referred to as
“above-the-fold”. “Landing area” may be interpreted to mean the whole landing
page. Perhaps repliers were confused by the phrasing.

~~~
macando
Bingo! Above the fold is the more common term. I usually call it "landing
area" and the whole thing I call "landing page". Naming is important :)

------
Zekio
Does this apply to all browsers on mobile?

Because I've never experienced this in Firefox on android

~~~
chanind
Firefox on Android works properly iirc, but sadly most users don't use it.

~~~
GoToRO
My proposal is to not fix anything and let people see that the other browsers
are worse.

------
missblit
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).

[1] [https://developers.google.com/web/updates/2016/12/url-bar-
re...](https://developers.google.com/web/updates/2016/12/url-bar-resizing) [2]
[https://bugs.chromium.org/p/chromium/issues/detail?id=428132](https://bugs.chromium.org/p/chromium/issues/detail?id=428132)
[3]
[https://github.com/bokand/URLBarSizing](https://github.com/bokand/URLBarSizing)

------
jariz
Using JS over CSS for sizing elements rarely is a 'better solution', mostly
because of flashes of unstyled content - _especially_ on mobile where it might
take longer for the JS to fully initialise.

Like other comments on here say, just use height: 100% instead.

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

------
jjcm
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.

------
sidyapa
There's a better solution for 100vh on mobile by csstricks - [https://css-
tricks.com/the-trick-to-viewport-units-on-mobile...](https://css-
tricks.com/the-trick-to-viewport-units-on-mobile/)

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

~~~
masklinn
> The fact that they include scrollbars on the document element

What do you mean by that? Do you mean that the surface taken by scrollbars is
not removed from the viewport?

That would make sense on mobile devices as scrollbars are generally transient
overlays, or when e.g. OSX is set up in that configuration (there's a system
setting so native scrollbars can be either a transient overlay or a reserved
area).

~~~
azangru
> the surface taken by scrollbars is not removed from the viewport?

Yes.

Which means that if your element's width is 100vw and the page height is
larger than the viewport height so that it shows a vertical scrollbar, then
suddenly you get a horizontal scrollbar as well.

People who build sites on Macs make this mistake all the time, because on
MacOS browsers hide their scrollbars by default, and developers do not
immediately see the consequences of this CSS rule. When you view these pages
on Linux or Windows machines (or if you tell MacOS not to hide scrollbars),
then you see the annoying horizontal scrollbar.

~~~
masklinn
> Which means that if your element's width is 100vw and the page height is
> larger than the viewport height so that it shows a vertical scrollbar, then
> suddenly you get a horizontal scrollbar as well.

Oh wow that's insane.

edit: apparently the "useful" behaviour used to be opted-in using overflow:
scroll, but only firefox implemented that, they asked if it was really useful
(when nobody else cared) and… it was dropped from the spec.

------
greggman2
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

------
sheerun
This issue has been reported at least 4 years ago to Webkit:
[https://bugs.webkit.org/show_bug.cgi?id=141832](https://bugs.webkit.org/show_bug.cgi?id=141832)

------
benbristow
I'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?

~~~
markdown
Use the flexbox solution instead:
[https://news.ycombinator.com/item?id=21110985](https://news.ycombinator.com/item?id=21110985)

~~~
benbristow
Still uses min-height: 100vh;

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

------
cyptus
stackoverflow discussion and more Infos on this:
[https://stackoverflow.com/q/37112218/1216595](https://stackoverflow.com/q/37112218/1216595)

------
LoSboccacc
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

