Readit News logoReadit News
chrenn · 6 years ago
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.

uallo · 6 years ago
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...

eloff · 6 years ago
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 · 6 years ago
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.
hyfgfh · 6 years ago
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...

abdusco · 6 years ago
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 · 6 years ago
Wouldn't this change after 16m 40s?
wereHamster · 6 years ago
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.

Deleted Comment

pritambarhate · 6 years ago
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 · 6 years ago
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 · 6 years ago
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- · 6 years ago
Or you use position:fixed?
Zekio · 6 years ago
Does this apply to all browsers on mobile?

Because I've never experienced this in Firefox on android

uallo · 6 years ago
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).
masklinn · 6 years ago
> 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.

chanind · 6 years ago
Firefox on Android works properly iirc, but sadly most users don't use it.

Deleted Comment

GoToRO · 6 years ago
My proposal is to not fix anything and let people see that the other browsers are worse.
missblit · 6 years ago
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