DEV Community

Don't use 100vh for mobile responsive

⚡ Nirazan Basnet ⚡ on May 04, 2022

Generally, we use height:100vh for fullscreen layout which is easy hack and convenient way to get better design. Example .content { ...

Read full post

JoelBonetR 🥇 • May 4 '22

You never should use static measurements to set a height nor a width unless it's completely necessary.

On the other hand, using min-height: 100vh; is totally Ok.
Or:

height: 100vh; 
overflow-y: scroll;

depending on what you want to achieve

Ivan Jeremic • May 4 '22

window innerHeight is safer and there are observers which you can use, I have a powerful React hook which does this, using 100vh is unsafe to use and very likely to break in some browsers.

JoelBonetR 🥇 • May 4 '22 • Edited

I'm not supporting IE since long time ago plus checked the usage for Opera Mini since 5 years ago in multiple webapps in production with hundreds of thousands of users, still got 0%: caniuse.com/viewport-units

Using JavaScript has some drawbacks as well:

When using SSR you can not pre-render window/document API-related stuff. So you need to defer this to the client, which usually deals to CLS (Cumulative Layout Shifting) and thus a worse user-experience and a worse score in core web vitals, which lowers your SEO.
You need to observe a given identifier to know when it exists, otherwise you can get a "Can't get innerHeight of undefined", which means you add an extra event-listener i.e. resize event.
If you use anu Reactive library or framework such React, adding those listeners on a Hook will cause a re-render since the beginning.
It's slower than CSS Only approach.

In CSS you can also use a calc to extract the navbar size if not fixed just like that:

.containerElement {
  min-width: calc(100vh - 80px);
}

Plus using min-height this way lets the content to grow more than a viewport if it's needed automagically (smartphone in landscape is a good test for that).

Note that the first one grows more than a viewport due to its texts getting more space.
The last one is just a viewport height. 😁

Ivan Jeremic • May 4 '22

Re-render on window size change is not a problem since this is a very rare event and it really on re-renders on size change. Also Safari mobile has lots of problems with 100vh

JoelBonetR 🥇 • May 5 '22 • Edited

Not at all. Issues related with smartphone try to artificially alter the behavior based on observation of the outer picture.

I mean, the browser UI is not part of the DOM, hence it will look the same in any website.

While altering your site based on browser+device makes your webApp consistent across-devices, usually an individual who's used to a given browser or a given device will expect that things to happen.

Moreover converting your WebApp into a PWA or making a native webview for iOS and/or Android, will behave different than opening it in the browser.

So each approach has pros and cons, just need to define whad do you really need for that specific use-case. 😊

Last but not least, let me introduce you to @supports feature query: spec, in which you can add vendor prefixed conditions to know which browser rendered your webApp and thus apply a calc on it like that:

@supports (-moz-appearance:meterbar) {
  /* We're on Mozilla! */
  min-height: calc(100vh - 20px);
}

Or using Browser Hacks:

@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
   /* We are on Internet Explorer! */
   min-height: calc(100vh - 10px);
}

Hope it helps somehow

Alex Lohr • May 6 '22

Fun fact: I'm actually the guy who came up with the msie10+ detection hack you mention in your last example.

Unfortunately, since the wrongful handling of 100vh in mobile browsers is not by a fixed height, you can only using the maximum deviation to fix the issue, which then results in large parts of the screen being unused.

Also, reading innerHeight and writing it to a CSS variable won't take too much time and CPU cycles; detecting scroll movements that should trigger the issue and removing the listener if it doesn't arise will be much more involved.

Nicholas Stimpson • May 4 '22

Coming soon: lv*, sv* & dv* units to address this issue.

Guillaume M. • May 5 '22 • Edited

Wow that's interesting.

Until its validation, I wonder how the css env() function could be used to solve our 100vh issue. (it already has a quite broad browser support)

⚡ Nirazan Basnet ⚡ • May 6 '22 • Edited

Earlier I tried using env() but it doesn't solve my issue so need to revert back.

⚡ Nirazan Basnet ⚡ • May 4 '22

Might be helpful but does not know anything about this so far :)

Ben Halpern • May 4 '22

This seems like a really useful pattern for using CSS variables in general. Thanks for the post.

Of course, for a lot of use cases the added complexity might not be worth the UX wins vs a slightly alternative design choice. Ultimately it's about helping the user do a thing they came to do, and roundabout complexity isn't exactly helping all the time. But figuring that out and agreeing on it with the designer is easier said than done!

IMO this sort of thing is best approached with a sense of repeating this pattern consistently where needed for styling to ensure it's not a one-off. 🙂

Andrew Nosov • May 11 '22

Cool solution, it helped me, thank you! In addition I've improved this approach with some debounce mechanism (setTimeout) that will limit count of function executions.

let timeoutId = null;
const documentHeight = () => {
  clearTimeout(timeoutId); // avoid execution of previous timeouts
  timeoutId = setTimeout(() => {
   const doc = document.documentElement;
   doc.style.setProperty('--doc-height', `${window.innerHeight}px`)
  }, 200);
};
window.addEventListener(‘resize’, documentHeight);
documentHeight();

⚡ Nirazan Basnet ⚡ • May 12 '22

Tankyou !! Appreciated :)

GreggHume • Jun 13 '23

Sometimes debouncing cost more then running the code itself. Just as an FYI.

Ben Read • May 5 '22

So this is a bit of a heated topic isn’t it?! Whilst I applaud your ingenuity I’d be careful about doing this kind of thing with JsS, or as some users suggest, doing a calc- because that assumes you know the height of that element.

Instead use -webkit-fill-available

Here’s some more information about that css rule: allthingssmitty.com/2020/05/11/css...

This situation is far from ideal and I know the Safari team are working hard to address these issues so they don’t become “the next IE”.

Ryan Pearson • May 6 '22 • Edited

This is a good option if you DONT need to use css Calc() function
ex:

body {
min-height: calc(100vh-70px);
/* mobile viewport bug fix */
min-height: -webkit-fill-available;
}

The webkit solution would not take into account the 70px adjustment

I've used the JS solution described in this post and it seems to be the best available option at the moment (until the new dynamic viewport units are adopted)

⚡ Nirazan Basnet ⚡ • May 7 '22

Thanks for using this solution 👍

leob • May 4 '22

Meaning, most people are doing this wrong? Or maybe most people already know this?

⚡ Nirazan Basnet ⚡ • May 4 '22

Due to browser dependencies and layout issue we need to tackle this kind of problem so it depends on project requirement. But, I suggest not to use 100vh on smaller devices.

Andrew Baisden • May 9 '22

Many ways to solve the same problem.

Liviu Lupei • May 5 '22

Nicely done for thinking of cross-browser issues.
I'm using Safari on my phone.

⚡ Nirazan Basnet ⚡ • May 7 '22

Thank you 👍

Ambriel Goshi • May 20 '22

This is helpful.

⚡ Nirazan Basnet ⚡ • May 22 '22

Thanks 👍

Kelsey Jones • May 20 '22

Glad I came across this.

⚡ Nirazan Basnet ⚡ • May 22 '22

Thanks 👍

IDRESS BENCHELLALI • May 12 '22

Thank you for this great article!

⚡ Nirazan Basnet ⚡ • May 16 '22

Your welcome :)

⚡ Nirazan Basnet ⚡ • May 22 '22

Glad this helped you

Pace Dev • May 15 '22

So thanks uuu

balchen • Aug 10 '22

I'm experiencing the exact same problem, and came across this post (among many others on the same subject). While it does fix the issue for Android and iOS devices, it breaks the page for desktop (Chrome and Firefox, at least).

The scrollbar I don't want now appears on desktop.

If I subtract 1px from innerHeight in the code, there's no scroll bar on desktop. It's a hack. Don't know why 1px makes the difference in this case.

piarey • Feb 5 '23

!!!!! This solution still has serious problems. !!!!!

1.
(iOS 15.2)
(when the content length is less than the viewport height)
"When the swipe down refresh function is exposed" ===>>> This action triggers the "Resize" event.

In other words, if you keep trying to swipe down, the continuously calculated height value will decrease, eventually creating a blank space at the bottom.

2.
What if the length of the content is between height: 100% and 100vh???
(iOS15.0.2) 100vh - A blank space is created at the bottom as much as the length of the content.

==========

Even so, are you still going to treat this situation as normal?
iOS is the re-advent of IE.