Re: [w3ctag/design-reviews] [css-values-4] The Large, Small, and Dynamic Viewport Sizes (Issue #706)

## Summary of Problem

Authors have many use-cases for sizing and/or positioning things relative to the viewport, and CSS has had viewport units to allow this for many years. What they mean by 'viewport', tho, varies on a case-by-case basis when mobile viewports are in play, because browsers dynamically show and hide parts of the browser UI (and thus what amount of viewport is "visible") according to user interaction.

Some use-cases want to size/position things *conservatively*; no matter what UI is shown or hidden, the elements must never be obscured by that UI - toolbars or other controls, for instance. Others want to size/position things *liberally*; filling the viewport in the optimal case (after the user starts scrolling, when those hideable UI elements get hidden), where it's fine for the content to be somewhat obscured in less-optimal cases - full-screen images, for example.

Many of these use-cases would like to size/position to the size of the viewport *dynamically*, changing size as parts of the UI are shown/hidden, but that has its own set of issues: it can have bad performance as content reflows repeatedly; it can have bad user experience as things off-screen resize and cause the on-screen content to shift in response.

The overall conclusion reached by the CSSWG is that there *is* no single correct answer across these cases, and the failure states of choosing any single answer are sufficiently bad to justify handling all three of them explicitly instead.  See [blogposts like this](https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html) for people complaining about the behavior of the existing single set of viewport units, or [this CSSWG issue thread](https://github.com/w3c/csswg-drafts/issues/4329) which had over a hundred comments, many from authors complaining about the current viewport unit behavior and/or the idea of settling on any one particular behavior.

## Solution

The CSSWG resolved (across several meetings for [small viewport](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-577169195) ([formatted](https://lists.w3.org/Archives/Public/www-style/2020Feb/0007.html)), [large viewport](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-814281379) ([formatted](https://lists.w3.org/Archives/Public/www-style/2021May/0010.html)), and [dynamic viewport](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-880040513) ([formatted](https://lists.w3.org/Archives/Public/www-style/2021Jul/0008.html)) units) to adopt three sets of viewport units, now known as "small", "large", and "dynamic" viewport units. These use a common prefix style atop the existing viewport units - sv*, lv*, and dv*. They are specified in [CSS Values & Units 4](https://andreubotella.com/csswg-auto-build/css-values-4/#viewport-relative-lengths).

## Examples

For example, to size and position content "above the fold" on initial page load, such as titles or navigation controls, the small viewport units can be used to ensure they will be visible on first page load or when scrolled to the top at any other point, but will not cause subsequent content to shift around later when scrolling.

For another example, photographs within a news article often want to be fullscreen, but don't mind being slightly cropped when the UI is expanded. They also do not want surrounding content to shift as UI is expanded or hidden, so they can use the "large viewport" units to get a stable viewport-filling size.

For a final example, "floating" navigation controls that remain on-screen as the user scrolls may want to fill the viewport, and ideally remain filled as the viewport changes size. As the controls are absolutely positioned, their changing size will not cause content shifts elsewhere, so they can safely use the "dynamic viewport" units to achieve this, never under- or over-flowing the visible viewport.

## Discussion Venues

* The original discussion about these units took place in [issue 4329 of the CSSWG repo](https://github.com/w3c/csswg-drafts/issues/4329) and several face-to-face meetings. That issue is now closed, since the WG resolved on the units and the spec text was written and approved.
* Further discussion about specifically adding the "large" viewport units took place in [issue 6113 of the CSSWG repo](https://github.com/w3c/csswg-drafts/issues/6113); also now closed due to the topic having been exhausted.
* New issues can be [raised in the CSSWG repo](https://github.com/w3c/csswg-drafts/issues/new); please include `[css-values-4]` in the issue title.

## Alternatives

Originally, the CSSWG attempted to leave the definition of viewport units on mobile browsers up to the UA to determine. This didn't work out, as explained above, because no single definition can satisfy all use-cases.

The other syntax solution considered was environment variables (the env() function), but because these are a perfect analog of the existing viewport units, and because these are frequently used as multiples/fractions of the "viewport size" (whereas existing environment variables like "safe area" are typically used directly, not multiplied by any factor) which is the purpose of having unit syntax in the first place, this alternative was rejected in favor of new units.

## Accessibility, Security, Privacy

We don't believe this introduces any new a11y or security implications.

It does provide an immediate leak of slightly more viewport sizes than JS can otherwise immediately obtain on page load, but that information becomes available to JS as soon as the user scrolls anyway.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/706#issuecomment-1082421111
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/706/1082421111@github.com>