Discussion on: Don't use 100vh for mobile responsive

[JoelBonetR 🥇]

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]

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 🥇]

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]

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 🥇]

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]

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.

[JoelBonetR 🥇]

Sure that last paragraph is what solves any situation I can think off, there's no point of discussion here.

I'm trying to define in my head all the situations in which that makes a real difference and not just a "some pixels extra-scroll" thingy, and asking me "is there any alternative way?" Just because linking information is the way I can remember something for years plus I usualy learn something else while trying to answer the question 😅.

[Ivan Jeremic]

@joelbonetr I don't support IE too but we have a new IE on the block called Safari which is the worst in implementing standards and compatible APIs. They are literally thinking browsers are not needed anymore and in a few years they are gone and everything is an app...

[JoelBonetR 🥇]

Hahaha I know, they have implemented better flex compat in the last 2 years at least, it was a pain in the ass before that but yes, Safari is the new IE.

I work with Windows 11 + WSLg in my personal desktop and Windows 10 + WSL2 in company's laptop so I bought an iPad mini just to test things in Safari as reference (or in any browser because in iPad OS or iOS all browsers rely on Safari 😐).

[Daniel]

@joelbonetr

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

Just embed the script before the content like so:

<script>
function calcVh() { document.style.setProperty("--100vh", `${window.innerHeight}px`); }
calcVh();
</script>

No issues with SSR and SEO at all.

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.

A drop in the sea. Just add to the script above the following:

window.addEventListener("resize", calcVh);

[⚡ Nirazan Basnet ⚡]

Here, I am not using static measurements. From js we can detect the app height and it automatically fits it and when we encounter browsers address bar then using 100vh does not solve the problem. In my case, above code doesn't solve the issue. But thanks for the reply.

[JoelBonetR 🥇]

Positioning the bottom bar with

position: fixed;
left: 0;
right: 0;
bottom: 0;

will fix your nav bar to the bottom without issues, then you can get the scroll to modify it's position to ptovide a js effect or to trigger a keyframe

[Yih Sev]

issues on mobile with vh..html, body, .some-page-wrapper { height: 100% } usually works even without JS... for most basic layouts. Then you don't have to use 100vh

[JoelBonetR 🥇]

min-height: 100vh is meant for when you want some block to have at least the height of the viewport's height. You cannot use % on those situations.
Moreover, height 100% (which means the height of its content without taking into account the padding nor the margin) is the default implicit behavior on any div, section, aside...

Edit: WRONG, see comment below

[Yih Sev]

I completely understand how 100vh and % works. I think you misunderstood the context of the post. If you meant to make the body 100vh, basically setting the html, and the body to 100% is the same thing as setting the body to 100vh. duhhh! But the thing is, using the % method doesn't give you the issues mentioned in the post when viewing the layout on mobile phones.

ANdI think you misunderstood how height 100% works in the context of my answer. What you are saying is definitely wrong - go test it yourself if setting both html, and body to 100% isn't the same thing as setting the body to 100vh.. maybe you need to learn how setting the height to percentage works if you have set the height of the parent. for a percentage value to work for height, the parent's height must be determined, and in this case setting HTML and the body to 100% does fill the whole viewport height(and yet doesn't cause the issues mentioned on mobile devices)

[JoelBonetR 🥇]

@esspetess oh sorry you're right, I misunderstood the comment (6 months old post 😂). Still you should use min-height instead of height property, otherwise if the content exceeds the container it will overlap with the following container and cause weird effects.

Have a great day