[css-values-4] The Large, Small, and Dynamic Viewport Sizes

[andruud]

Braw mornin' TAG!

I'm requesting a TAG review of the new lv*, sv*, dv*, vi, vb units.

The new units are similar to the existing viewport units (vw, vh), except that they take into account the size of expandable/collapsible browser UI in a few different ways.

• Explainer:
  • This brief article explains it well: https://www.bram.us/2021/07/08/the-large-small-and-dynamic-viewports/
  • Even more brief article which shows the problem with the existing units: https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html
• Specification URL: https://drafts.csswg.org/css-values-4/#viewport-variants
• Tests: N/A, unfortunately WPT can't cover the dynamic UI aspects of this.
• User research:
• Security and Privacy self-review: Does not expose new information that's not already exposed via JS.
• GitHub repo: https://github.com/w3c/csswg-drafts
• Primary contacts:
  • @andruud, Google, Working on the implementation in Chromium.
• Organization(s)/project(s) driving the specification: CSSWG
• Key pieces of existing multi-stakeholder review or discussion of this specification:
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Q1 2022
• The group where the work on this specification is currently being done: CSSWG
• Major unresolved issues with or opposition to this specification:
  • Not necessarily major nor opposition, but maybe interesting:
    [css-values-4] Large, small and dynamic viewport units (lvh, svh & dvh) don't solve top level horizontal scrolling use cases w3c/csswg-drafts#6551
    [css-values-4] viewport units vs initial containing block w3c/csswg-drafts#6453
• This work is being funded by:

You should also know that...

• Safari has recently shipped support for these units.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[torgo]

Hi @andruud can you please let us know if there's an explainer for this beyond what you've linked to?

[atanassov]

Hi again @andruud,

Despite use cases being somewhat obvious, we encourage use of the explainer template in order to capture all the other important bits in a single place - other considerations, code examples, privacy, security and a11y considerations etc. Can you please write one?

We took a look at this in our hybrid meeting today. Since an explainer is still missing, we're going to go ahead and close this for now. Please feel free to reopen once there's an explainer, as I suspect the rest of the review will be rather straightforward.

Cheers, @torgo and @atanassov

[tabatkins]

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 for people complaining about the behavior of the existing single set of viewport units, or this CSSWG issue thread 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 (formatted), large viewport (formatted), and dynamic viewport (formatted) 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.

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 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; also now closed due to the topic having been exhausted.
• New issues can be raised in the CSSWG repo; 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.

[torgo]

Thanks @tabatkins I'm reopening and putting this on our agenda for next week. 👍🏻

[atanassov]

Hi @andruud and @tabatkins, thank you for the patience with this review and apologies it's taken so long to get you feedback. We are happy to see this work move forward through CSSWG, and we note positively the multi-stakeholder support.

Good luck and please engage with us again in case of any major changes.