The CSS Working Group (CSSWG) has recently published an updated working draft of the CSS Values and Units Level 4 specification â a document describing CSS grammar definition and value types.
This update brought a few interesting features, among which are new viewport units. Letâs see what they are and how they work!
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
Weâll start with a quick revision of the current viewport-relative units.
Viewport-percentage length units, or so-called viewport-relative units, are CSS units relative to the initial containing block, a rectangle where the root (<html>) element is located. The block itself is based on the viewportâs size (usually the browser window or iframe), hence the name of the unitsâ category.
In this category, there are four units you should already be familiar with:
vw â 1% of the viewportâs widthvh â 1% of the viewportâs heightvmin â smaller of vw or vhvmax â larger of vw or vhThe above units are available in all modern browsers, with support going back to IE 10 (except for the vmax unit).
Youâll usually see the units in action for page elements such as modals, overlays, and others, powering full-screen experiences.
Now, apart from the above four units, the new specification actually defines two others: vi and vb. Theyâve been a part of Level 4 for quite a while, but still arenât supported by any well-known browser. Still, they exist, meaning that eventually browsers will support them, so itâs worth knowing how theyâre meant to work.
Both units are dependent upon the writing-mode property, making their values bound 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 directionIn languages written horizontally, like English, the 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.
Before we get to the new units, we first need to understand why they are being introduced.
The problem lies in the User-Agent interface, a.k.a., the browserâs UI.
While browsers usually have access to large screen estate on desktop, the same canât be said for mobile. Thatâs why mobile browsers often minimize their UI â like the search bar â to save space when the user scrolls.
This allows for more content to be visible on the screen at one time, but introduces a problem: how should viewport-relative units be implemented?
Historically, the unitsâ actual values were shifted to adapt to the browserâs current UI state. This proved to be bad for user experience due to content constantly shifting while the user was scrolling.
So, Safari, Chrome (about a year later), and the other browser vendors changed this behavior to make viewport-relative units dependent on the viewport size when the browserâs UI is minimized. This fixed some issues but introduced new ones.
Now, using 100 with any viewport unit meant risking part of the page being hidden by the browserâs UI when it was maximized. This, in turn, led to such practices becoming an anti-pattern on mobile, forcing developers to implement JavaScript workarounds.
Thatâs where the new units and specification updates step in.
In truth, the new units arenât really new. Instead, theyâre just variants of the already-existing units weâve covered above, differentiated by viewport sizing.
Letâs see what that means.
The current units starting with v* are now officially known as UA-default viewport-percentage units, and their implementation of viewport size depends on the User-Agent. This means that the behavior of these units can differ between browsers while keeping in mind the current, unofficial, industry standard.
So, to reiterate â nothing new here. The vh, vw, vmin, vmax, vb, and vi units remain as they were in the specs before the change. This ensures backward compatibility.
Now, things get interesting when we get into large and small viewport-percentage units. As the name implies, these units put specific requirements on how the UA should size its viewport.
For large viewport units, the viewport must be sized to allow for the largest possible viewport, assuming any dynamic browser UI is retracted. This allows the developer to make their designs fill the entire viewport while keeping in mind that the browser UI could overlap at least part of it.
This large viewport variant starts with lv* and includes lvh, lvw, lvmin, lvmax, lvb, and lvi.
For small viewport units, itâs the exact opposite. In their case, the viewport must be sized assuming any dynamic interface is expanded, determining the smallest possible viewport. This ensures that the developerâs designs fill the entire viewport when the UA interface is expanded, while possibly leaving empty spaces when the UI is retracted.
This small viewport variant starts with sv* and includes svh, svw, svmin, svmax, svb, and svi.
Lastly, there are also dynamic viewport-percentage units. These will allow developers to use the âhistoricalâ behavior where the viewport sizing â and thus units values â depend upon whether the browser interface is expanded or retracted.
While this means more control and choice for developers, this variant comes with a warning.
Using it can cause the content to shift, degrading the UX. Other things to consider are the performance hit and possible animations during recalculations. Those can either improve or further degrade the UX, depending on UAâs implementation.
The dynamic viewport variant starts with dv* and includes dvh, dvw, dvmin, dvmax, dvb, and dvi.
Overall, the new viewport-relative units in the specification mean developers have more precise control over the decisions they make about how their designs should behave in relation to their usersâ viewports.
However, with great power comes great responsibility. When the new units eventually arrive in browsers, for developers, itâll mean not only one more thing to control but also one more thing to keep in mind. While vendors will definitely do their best to implement the units wisely, itâll now be even more important for developers to ensure and deliver a good user experience than before.
As web frontends get increasingly complex, resource-greedy features demand more and more from the browser. If youâre interested in monitoring and tracking client-side CPU usage, memory usage, and more for all of your users in production, try LogRocket.
LogRocket lets you replay user sessions, eliminating guesswork around why bugs happen by showing exactly what users experienced. It captures console logs, errors, network requests, and pixel-perfect DOM recordings â compatible with all frameworks.
LogRocket's Galileo AI watches sessions for you, instantly identifying and explaining user struggles with automated monitoring of your entire product experience.
Modernize how you debug web and mobile apps â start monitoring for free.
Build a CRUD REST API with Node.js, Express, and PostgreSQL, then modernize it with ES modules, async/await, built-in Express middleware, and safer config handling.
Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the March 25th issue.
Discover a practical framework for redesigning your senior developer hiring process to screen for real diagnostic skill.
I tested the Speculation Rules API in a real project to see if it actually improves navigation speed. Hereâs what worked, what didnât, and where itâs worth using.
Would you be interested in joining LogRocket's developer community?
Join LogRocketâs Content Advisory Board. Youâll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn more â
