11 ms·

Avoid 100vh on Mobile Web

71 points by chanind 7y ago

Zekio 7y ago
Does this apply to all browsers on mobile? Because I've never experienced this in Firefox on android
- chanind 7y ago
  Firefox on Android works properly iirc, but sadly most users don't use it.
  - deleted 7y ago
    [deleted]
  - GoToRO 7y ago
    My proposal is to not fix anything and let people see that the other browsers are worse.
- uallo 7y 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 7y 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.
    - uallo 7y ago
      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.
      - brlewis 7y ago
        Subtle changes during scrolling seem way preferable to me than hiding content that, according to standards, should be shown.
eloff 7y 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.
- hyfgfh 7y 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...
- greggman2 7y 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.
uallo 7y 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-than-the-visible-part-of-the-document-in-some-mobile-browsers.html https://nicolas-hoizey.com/2015/02/viewport-height-is-taller...
abdusco 7y 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 7y ago
  Wouldn't this change after 16m 40s?
  - wereHamster 7y 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 7y ago
  [deleted]
jjcm 7y ago
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.
macando 7y ago
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.
benbristow 7y ago
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 7y ago
  Use the flexbox solution instead: https://news.ycombinator.com/item?id=21110985 https://news.ycombinator.com/item?id=21110985
  - benbristow 7y ago
    Still uses min-height: 100vh;
- greggman2 7y ago
  I believe on mobile safari and chomre your footer will be off the bottom until the user scrolls down and the browser us shrinks
dessant 7y ago
As one of the comments below the post mentions, `html, body {height: 100%}` should work just fine.
tsar_nikolai 7y 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 7y 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- 7y ago
    Or you use position:fixed?
    - macando 7y ago
      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 7y ago
        Set top: 0; bottom: 0
        macando 7y ago
        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.
chrismorgan 7y ago
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 7y ago
  > 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 7y ago
    > 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 7y ago
      > 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.
    - deleted 7y ago
      [deleted]
LoSboccacc 7y ago
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
sheerun 7y ago
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
cyptus 7y ago
stackoverflow discussion and more Infos on this: https://stackoverflow.com/q/37112218/1216595 https://stackoverflow.com/q/37112218/1216595
greggman2 7y ago
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
sidyapa 7y ago
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...
chrenn 7y 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 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.
jariz 7y ago
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.
pritambarhate 7y 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.
missblit 7y 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-resizing https://developers.google.com/web/updates/2016/12/url-bar-re... [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

71 points by chanind 7y ago

Zekio 7y ago

Does this apply to all browsers on mobile? Because I've never experienced this in Firefox on android

chanind 7y ago
Firefox on Android works properly iirc, but sadly most users don't use it.
- deleted 7y ago
  [deleted]
- GoToRO 7y ago
  My proposal is to not fix anything and let people see that the other browsers are worse.
uallo 7y 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 7y 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.
  - uallo 7y ago
    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.
    - brlewis 7y ago
      Subtle changes during scrolling seem way preferable to me than hiding content that, according to standards, should be shown.

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

hyfgfh 7y 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...
greggman2 7y 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.

uallo 7y 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-than-the-visible-part-of-the-document-in-some-mobile-browsers.html https://nicolas-hoizey.com/2015/02/viewport-height-is-taller...

abdusco 7y 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 7y ago
Wouldn't this change after 16m 40s?
- wereHamster 7y 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 7y ago
[deleted]

jjcm 7y ago

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.

macando 7y ago

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.

benbristow 7y ago

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 7y ago
Use the flexbox solution instead: https://news.ycombinator.com/item?id=21110985 https://news.ycombinator.com/item?id=21110985
- benbristow 7y ago
  Still uses min-height: 100vh;
greggman2 7y ago
I believe on mobile safari and chomre your footer will be off the bottom until the user scrolls down and the browser us shrinks

dessant 7y ago

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

tsar_nikolai 7y 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 7y 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- 7y ago
  Or you use position:fixed?
  - macando 7y ago
    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 7y ago
      Set top: 0; bottom: 0
      - macando 7y ago
        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.

chrismorgan 7y ago

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 7y ago
> 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 7y ago
  > 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 7y ago
    > 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.
  - deleted 7y ago
    [deleted]

LoSboccacc 7y ago

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

sheerun 7y ago

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

cyptus 7y ago

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

greggman2 7y ago

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

sidyapa 7y ago

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

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

jariz 7y ago

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.

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

missblit 7y 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-resizing https://developers.google.com/web/updates/2016/12/url-bar-re... [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