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,

    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.

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

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

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.

Wouldn't this change after 16m 40s?

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.

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.

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.

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

Or you use position:fixed?

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.

Set top: 0; bottom: 0

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.

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

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 :)

Does this apply to all browsers on mobile?

Because I've never experienced this in Firefox on android

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.

Most of the time, yes. But the layout might jump just because you scroll up/down a little. For example, the spacings might get slightly larger when you scroll down and slightly smaller when you scroll up.

Subtle changes during scrolling seem way preferable to me than hiding content that, according to standards, should be shown.

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

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

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... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=428132 [3] https://github.com/bokand/URLBarSizing

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.

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.

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's a better solution for 100vh on mobile by csstricks - https://css-tricks.com/the-trick-to-viewport-units-on-mobile...

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.

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

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

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

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: https://bugs.webkit.org/show_bug.cgi?id=141832

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?

Use the flexbox solution instead: https://news.ycombinator.com/item?id=21110985

Still uses min-height: 100vh;

I believe on mobile safari and chomre your footer will be off the bottom until the user scrolls down and the browser us shrinks

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

stackoverflow discussion and more Infos on this: https://stackoverflow.com/q/37112218/1216595

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