Viewport Units Explained: Achieving Pixel-Perfect Mobile Displays

In the dynamic landscape of web development, crafting a seamless user experience across devices is paramount. However, a common stumbling block arises when trying to ensure that website content displays correctly on mobile devices. Despite setting an element's height to 100vh (representing 100% of the viewport height), users often find that their content remains scrollable. This issue stems from a fundamental miscalculation of the 100vh unit, which is optimised for desktop browsers and does not account for the presence of the browser's address bar on mobile devices. This discrepancy can lead to frustrating user experiences and design complications. In response, a new set of viewport units has been introduced to address these challenges, allowing for more precise control over page layout and presentation.

Exploring New Viewport Units with an Example

Have you ever encountered the frustrating issue of your website content being scrollable on your mobile device, even when you've explicitly set the element's height to 100vh (representing 100% of the viewport height)? If so, you're not alone.

This common problem occurs because the 100vh unit, which is meant to fill the entire vertical height of the viewport, is typically calculated with desktop browsers in mind. Desktop browsers don't account for the presence of the browser's address bar, so 100vh might work perfectly on a desktop browser but fall short on mobile devices.

To illustrate this issue further, let's take a look at the image below. Here, we've set both the height and width of an element to 100vh and 100vw, respectively, to make it occupy the entire screen without any scrolling. Now, let’s add a button at the bottom of the screen.

We can resolve this issue using several approaches. One effective method is employing positioning with 'bottom: 0'. By doing so, the button will stay at the bottom of the screen.

Everything is correct, and we don't have the scroll bar, but what's happening on the mobile side?

As you can see, initially, the button is not visible, and we can scroll the content. This behavior is a result of the dynamic toolbar, which includes elements like the address bar and tab bar on mobile devices, leading to different behaviors. When scrolling, the address bar becomes hidden, and the button becomes visible. In fact, the 100vh unit is calculated without including the address bar, causing the button to be initially placed out of view. This behavior can significantly impact your app's design.

To address this issue, new viewport units have been introduced. But first, let's define what 'small' and 'large' viewport means.

Based on the above image, the small viewport refers to the height of the container minus the address bar. (Note that here we have the Android devices and Chrome browser, it may be different in a different browser and iOS devices). On the other hand, the large viewport encompasses the size of the container, including the address bar.

Google's Definition of Viewports

Here is the definition from Google for these two terms:

• Large viewport: The viewport is sized assuming any User Agent (UA) interfaces that are dynamically expanded and retracted, to be retracted.
• Small viewport: The viewport is sized assuming any User Agent (UA) interfaces that are dynamically expanded and retracted, to be expanded. So, the new viewport units are designed to adhere to this assumption.

The large viewport units are denoted by the 'lv' prefix, for example, 'lvh' and 'lvw'. Conversely, the small viewport units are indicated with the 'sv' prefix, such as 'svh' and 'svw'.

Now, let's change the height of our example container to the values mentioned above and observe the changes.

As you can observe in the image on the left (height: svh), we have all the content on the page visible, even when the address bar is displayed. In this scenario, the page remains non-scrollable. However, when we assign a height of 'lvh', the button goes out of view, necessitating scrolling to access it.

In addition to these two units, we have the 'dv' prefix, which stands for dynamic viewport. This prefix indicates that it will adapt to either the small, in-between, or large units, depending on whether the address bar UI is shrunk or not. These units are represented as 'dvh' and 'dvw'.

Use cases

One example of a use case can be our scenario where we have elements positioned at the bottom, which are sticky to the footer. Another use case can be when we want to calculate the amount of space needed to achieve scrolling behavior on a table, as illustrated below.

Here we use the following CSS for the table container: .header, .footer{ height: 50px; } .table { height: calc(100svh - 100px); overflow-y: auto; }

Caveats

There are some caveats that are worth mentioning here:

• The size of the scrollbar is not taken into account when using horizontal (width) units.
• Calculations in dynamic mode are slightly more complex because the browser needs to calculate everything based on the toolbar's visibility. Additionally, the value will not be updated at a rate of 60 frames per second (60fps).
• The size of the virtual keyboard is not factored into the unit calculations and does not affect the units.

Conclusion

The discrepancy between desktop and mobile browsers in calculating viewport units like 100vh can lead to frustrating user experiences. The introduction of small (sv) and large (lv) viewport units, as well as dynamic viewport units (dv), provides developers with a nuanced toolkit to overcome these challenges. By understanding and utilising these units effectively, developers can ensure that their websites deliver a seamless, user-friendly experience across a wide array of devices and platforms. This level of precision is crucial in an era where accessibility and user satisfaction are at the forefront of digital design.