Get a better view: The Magic of Viewport Units

Viewport Units are a fine addition to the new CSS3 properties and allow us to calculate dimensions according to the actual size of the viewport, instead of the parent element (as it’s always been so far). There is a new precious tool for better and easier responsiveness that leads the way to a new approach, not only to the process of layout building, but also to web typography. 

Viewport width and height: an overview

Viewport Width (vw) and Viewport Height (vh) are units that define a relationship to the width or, respectively, the height of the viewport, and each of these units represents 1% of the total viewport . So we have:

    1vh = 1% viewport height
    1vw = 1% viewport width
    100vh = viewport height
    10vw = 10% viewport width

At first glance, one might wonder whether there is any difference between width= 100vw and width= 100%; of course there is, and it’s a pretty big one. An element that has 100% width is exactly as wide as its container while another one with a width of 100vw will always have the size of the viewport.

This becomes more clear when considering the height, since a block level element, for its default behaviour, will widen itself as much as possible, but it will be just high enough for the content to fit in. An element with a height of 100% will cover the viewport only if its parent does, something you can achieve by assigning a 100% width to the html and body element; an element with a height of 100vh will always extend to the browser window’s height. 

There’s an intuitive and quick use for Viewport Height, namely if we need a series of layers with a nice background image that covers the viewport entirely: just setting the layers' height to 100vh plus a combination of background-size: cover; and background-position: center; will give us what we want on mobile as well without major adjustments.

But wait, there’s more: vmin and vmax

Vmin and vmax complete the specification of the Viewport Units. They express a percentage of the viewport’s largest (vmax) or smallest (vmin) side. Vmax is always the longest side of our window and it will be the width when we keep a mobile phone in landscape mode but, if we put it in portrait mode, vmax will become the height.

A headline that really fits

It’s a popular trend to have one big presentation headline just on the homepage of a website, but it always requires heavy resizing when we switch to mobile phones. In addition, one should provide an extra rule for the mobile screen’s orientation, since a headline that fits when we are in landscape view, will definitely be too large when we put the phone in portrait mode. 

We can solve this problem by binding the headline’s font-size to vmin; since it’s always the shortest side of the viewport, it will fit the screen even if we change the orientation. It’s highly recommended to use vmin instead of vmax since the former has better support. 

Viewport-based typography: a quick note

With the many devices and resolutions we need to consider in our development flow, using a fixed font size is certainly not a good idea, since it will inevitably be too small or too big for a large number of users. Usually, web designers solve this problem with media queries, setting up breakpoints for mobile, small screens and big ones: it’s an approach that usually brings positive results but it’s not easy to maintain, and it would be nice to have a rule that can define a size that fits all.

Viewport Units can surely aid on that topic, since they are bound directly to the viewport size, but binding the font size directly to a fixed percentage of the viewport (1%, for example) does not lead to optimal results. If we define font-size: 1vw, it will be definitely pretty good at medium resolutions, it’s 16px at 1600x1200, but totally unreadable on mobile when it’s shrunk to less than 4px. It would be much better if we could define a base font size and increase it according to the viewport:

body { font-size: calc(12px + 0.3vw) }

This returns a font size of roughly 13px on mobile, 15px on a 1024px resolution and 17px on a screen that is 1680px wide. However, some compatibility issues related to window resizing have been reported, so the following equivalent statement should have better support:

body { font-size: calc(75% + 0.3vw) }

How safe are they for today’s use?

Nowadays, almost every CSS3 property has a good overall support, and viewport units follow this trend with only IE8 and old iOS and Android versions (5.1 and 4.3, respectively) that lack full support. However that doesn’t mean that within the supported browsers everything is fine: the most serious issue relates to the scrollbars that are erroneously computed into a 100vw declaration (Firefox doesn’t have this issue) and this often requires an overflow-x: hidden fix. In addition, vmax is unsupported by IE9 and other more recent browsers (noteworthy is that it’s sister property, vmin, is fully supported).

The availability of the exact viewport height and the possibility to use it in production has always been one of the most awaited CSS features; combining calc() and viewport units helps us climb one step further towards full layout control. With the aid of Flexbox, and the upcoming CSS Grid, we could consider the process almost complete: time to move on to a new challenge!

More great blog posts from Alessandro Lo Verde

  • Grill.rb and Grill.js: One part food, One part drink and whole lot of programming

    Suppose that you want to buy a grill to have a small party with a couple of friends, and then you realize that you’ve placed the wrong order since a monster sized grill arrives at your door. You probably want to send it back, trying to explain that the size was missing from the item’s description...

  • This is how business gets done: Nuremberg Airport and Scrivito

    There are good CMS's out there, and many are fine tools to make blogs, websites for small business and even for a medium-sized one; but can they handle a large website, with a lot of data interaction that comes from external sources? What comes up if you need to build an intranet as well?...

  • Reverse Box Order on Mobile

    It’s a pretty common trend for many presentation websites to have a 3-column “feature box” where products or features are showcased. Since on mobile they would be squeezed too much, it’s a best practice to make these boxes 100% wide and place them one under each other, following the same order...

  • Getting Out of the Fixed Container

    Most of today's websites use a wrapping container element on their pages – for good reason: it’s handy to have an element that surrounds the content, allowing it to shrink and expand to given breakpoints. But our beloved container can sometimes be a prison (and not even a golden one) when we want...

  • Let's Embrace CSS3 Calc()

    Powerful and widely supported, this handy CSS3 property helps save us from headaches when dealing with layout and box model. Back in the day, everything on the web was coded in pixels, but as the desire for flexible design arose, font sizes were frequently defined in ems and more recently in...

  • Web Typography Done Right

    Typography is often a mixed blessing for the web: Developers tend to overlook it since it does not play an important part in their interests, and designers sometimes are disappointed about the limits of the web, compared to print design. And yet typography is what truly makes the difference...