Unlocking the Power of Viewport-Relative Units in CSS
The CSS Working Group has just released an updated working draft of the CSS Values and Units Level 4 specification, introducing exciting new features to the world of CSS. Among these innovations are new viewport units, designed to give developers more control over their designs and improve user experience.
Revisiting Viewport-Relative Units
Before diving into the new units, let’s refresh our understanding of viewport-percentage length units, also known as viewport-relative units. These units are relative to the initial containing block, which is based on the viewport’s size (typically the browser window or iframe). We’re familiar with four units in this category:
vw: 1% of the viewport’s widthvh: 1% of the viewport’s heightvmin: smaller ofvworvhvmax: larger ofvworvh
These units are widely supported in modern browsers, dating back to IE 10 (except for vmax). They’re commonly used to create full-screen experiences for page elements like modals and overlays.
Introducing New Units: vi and vb
The updated specification introduces two new units: vi and vb. Although they’re not yet supported by popular browsers, it’s essential to understand how they’ll work once implemented. Both units depend on the writing-mode property, making their values tied to the user’s language direction.
vi: 1% of the viewport’s size in the inline directionvb: 1% of the viewport’s size in the block direction
In languages written horizontally, like English, these units are equivalent to vw and vh, respectively. For vertically-written languages, like Japanese, the units are switched, making vi equal to vh and vb to vw.
The Browser UI Conundrum
To understand the need for new units, we must first address the issue of browser UI. On mobile devices, browsers often minimize their UI to save space when the user scrolls, allowing more content to be visible on the screen. However, this introduces a problem: how should viewport-relative units be implemented?
Historically, the units’ values were adjusted to adapt to the browser’s current UI state, leading to a poor user experience due to content shifting while scrolling. To fix this, browsers like Safari and Chrome changed their behavior to make viewport-relative units dependent on the viewport size when the UI is minimized. While this solved some issues, it introduced new ones, such as risking part of the page being hidden by the browser’s UI when maximized.
New Unit Variants: lv*, sv*, and dv*
The updated specification introduces three new unit variants: large viewport units (lv*), small viewport units (sv*), and dynamic viewport units (dv*). These variants offer more control and flexibility for developers.
- Large viewport units (
lv*): sized to allow for the largest possible viewport, assuming any dynamic browser UI is retracted. - Small viewport units (
sv*): sized assuming any dynamic interface is expanded, determining the smallest possible viewport. - Dynamic viewport units (
dv*): allow developers to use the “historical” behavior where the viewport sizing depends on whether the browser interface is expanded or retracted.
While these new units offer more precision, they also come with warnings. Using dynamic viewport units can cause content to shift, degrading the user experience. Additionally, there may be performance hits and possible animations during recalculations.
The Future of Viewport-Relative Units
The new viewport-relative units in the specification mean developers will have more control over their designs and how they behave in relation to users’ viewports. However, with great power comes great responsibility. When these units eventually arrive in browsers, developers will need to ensure they deliver a good user experience while keeping in mind the complexities of viewport-relative units.
Are you interested in monitoring and tracking client-side CPU usage, memory usage, and more for all your users in production? Try LogRocket, a DVR for web and mobile apps that records everything that happens in your app, allowing you to aggregate and report on key frontend performance metrics, replay user sessions, log network requests, and automatically surface all errors.