Hey Web Devs, stop using viewport height!
The problem with viewport heights and how to resolve it.
The problem with the vh unit is that it completely disregards the elements inside of any container that it’s applied to.
Ok that’s it, we’re done, we can go home now! Just kidding, here’s why that’s bad.
The Problem with Viewport Height (vh units)
If you use vh to set the height of your div, section, margin-top/bottom, padding-top/bottom, they now solely rely on your browser’s height to determine its own value.
This is BAD for responsiveness.
Reason being, most (if not all) web developers use media queries that target specific viewport WIDTHS, not heights. This is done so that we can achieve specific styles/layouts on different mobile devices and is crucial to app development. However, this gets flipped on its head when we’re talking solely about browsers. Why? Because browsers can be any height or width.
For example, you start mobile first with the iPhone SE (320x568). You give your div a height of 100vh because you want your div to take up the full height of your device. Now your div has the height of 568px because that’s the size of the iPhone SE’s viewport height.
You also give the h1 a font-size of 20px.
But what if you’re on a browser at 320px width and an unknown height?
The div now takes up the FULL height of the browser. This is my landing section with 100vh for its height. Your first thought is going to be “Why not just add a max height?” Sure, but what height? Most developers have multiple media queries based on specific device widths. But not all devices have the same height. You can tackle the iPhone 12 Pro Max, Pixel 2XL and browsers with the same media query at 400px width, but what if they have different heights? Yeah, you’ll come across problems there.
On laptops (1280x1024 for example), you set your font-size to 110px via media queries that target the 1280px width, but you left the div untouched because you like having your div fill up the entire screen. Now your div has a height of 1024px.
But what if you changed the height? You have NO media queries to detect this. You could make a media query for specific browser heights, but that’s a convoluted mess of a solution. Again, what height?
So what happens when you shrink the height of the browser? Your div shrinks while your font size stays at 110px. Here I’ve only shrunk the browser a little bit from 1024px to 921px in height.
Now I have a second scrollbar because my div couldn’t keep all of its content on screen! This happens because, as I’ve mentioned before, the boxes using the vh unit completely disregard their inner elements. It doesn’t care how much space its content needs. Because of this, it creates a second scrollbar in an attempt to show the rest of the content in the div.
So what’s the solution to this? Create media-queries for specific heights? No.
Just stop using vh, start using height:auto and padding.
What does height: auto do?
It makes your box prioritize the size of its content. It’s the default height of all elements, so you actually don’t even have to write that line in CSS. You then add padding to it to keep your elements from touching the borders. That’s it.
Here’s that same laptop size NOT using vh (actually, it’s a smaller height, just to reinforce this idea). Can you see the difference? No extra scrollbar!
Here’s that same desktop view of 320px width and 946px height.
As you can see, you can already see the second section. It’s not just a huge blank space.
To summarize: boxes using vh for its height don’t care about their content. This is bad for responsiveness. Instead, just use height: auto if you can. Then add in padding. The great thing about padding is that it helps keep your boxes CONSISTENT. This is important for designers. We’re not just making up random sizes for our boxes now!