Viewport Measurement (including new Viewport Units)

[jensimmons]

Description
Web developers struggle to measure the viewport in a consistent and predictable manner — especially the viewport in the block dimension on mobile devices, when often the browser UI changes size or disappears/reappears. After years of hearing developer frustrations about VH in particular, the CSSWG has defined new units to cover all usecases and web developers would benefit greatly from rapid implementation by browsers. -webkit-fill-available, window.inner-height, percent lengths, and environment variables (with & without fixed or sticky positioning) are also used to measure the viewport and size content/layout to fit. Ideally all of these would be as close to interoperable as possible, recognizing that browser UI is not something we standardize across browsers.

Specification

• New viewport units in CSS Values and Units Module Level 4
• CSS Environment Variables Module Level 1
• window.innerHeight in CSSOM View Module

Tests
TBD

Rationale
Looking at data from multiple surveys, and having talked to web developers for years (teaching about viewport units from stage), it's clear many web developers struggle to size content on mobile screens. They want to use viewport units instead of JavaScript to size elements, are often trying to create an app-like experience that fits the screen exactly, or are otherwise confounded by the browsers that have UI growing or shrinking at the top/bottom of a mobile screen.

The problem is a complex one, and developer often don't know how to express a solution. They instead describe the problem in a variety of ways. For example, from very early results of this year’s State of CSS survey alone:

• “viewport units”
• ”Full screen height is a pain to work with”
• “Can't use viewport units easily, because of Safari”
• “Viewport height/width (100vh/100vw being different on macOS vs. Windows, or different between mobile versus desktop)”
• “Screen Height”
• “iOS viewport sizing”
• “100% viewport width”
• “ios safari: vh and scroll behavior are always trouble”
• “100vh in Safari iOS”
• “state-dependent styling (e.g. styling of stuck, snapped, or on-screen elements)”
  and even more.

Developers often center their frustrations around iOS, but the same problem exists in mobile browsers on Android & other operating systems. The actual viewport size changes anytime a browser’s top/bottom UI changes state. And, it turns out, the vh/vw/vmin/vmax units alone do not solve everyone’s use cases at the same time.

The CSSWG did an in-depth analysis of this problem over the last several years, and came to the conclusion that the best solution to solve this is to create additional viewport units.

Let’s focus on viewport height.

• The new SVH unit will always return the height of the viewport if all of the UI was maximized (leaving the viewport the smallest possible size).
• LVH will always return the height of the viewport if all of the UI was minimized (leaving the viewport the largest possible size.)
• DVH stands for dynamic viewport height, a measurement that changes based on the current state of the UI, always returning the actual current value of the viewport height.

There are similar units for width, max and min — and to cover logical layout, the new inline and block dimensions. Please read the CSS Values and Units Module Level 4 specification to read about all of the new units.

We would like to propose inclusion of all of these new units in Interop 2022. They will solve most of the frustrations web developers are having with sizing their content to the viewport.

Developers have been begging for a solution to this for years.

[jensimmons]

WebKit: https://bugs.webkit.org/show_bug.cgi?id=219287
Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1610815
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1093055

[foolip]

This is a great proposal, thanks @jensimmons!

Frustration around this was also very prominent in the MDN browser compat survey and interview, see viewport findings for a summary. At the time I linked w3c/csswg-drafts#4329 and I'm happy to see the new units have been defined now.

Here's something I noted in the report back then:

While ​Chrome 56 changed its behavior to match Safari on iOS​, some developers may not have noticed this, and it remains difficult to achieve the desired effect.

That was in early 2020. Judging by the State of CSS 2021 responses, it seems like the impression still persists that 100vh does something different across mobile browsers. Some of this is probably a lack of awareness, but I wonder if there are some differences around "filling the viewport" that are still causing frustration. @bokand researched Input/Scrolling Interop Investigation 2020 and back then there were differences in when resize events are fired, for example.

Taking a close look together at differences in existing behavior would be great, so that if there's something many developers are running into, we can address that too and have a compelling message that we've made viewport units all around interoperable in 2022.

[tomayac]

+1 to this being a massive issue by talking to developers. Articles like The trick to viewport units on mobile (check the number of comments) are widely shared on Twitter and "solutions" like the -webkit-fill-available hack keep making the rounds, too.

[foolip]

I've now analyzed the "Are there any CSS features you have difficulties using because of differences between browsers?" questions from State of CSS 2021 in #7, and the Viewport category there is largely about this issue. Being up there close to Container Queries and :focus-visible despite not being mentioned previously in the survey, is a pretty strong signal of importance to me.

[jgraham]

Apologies, I just added an issue template for proposals, which I should have done much earlier.

Would you be able to rewrite the issue description to match that template?

[jensimmons]

I think it's a terrific idea to make this area be about nailing interoperability for the various ways web developers attempt to measure the Viewport — including JavaScript.

• existing viewport units, eg:height: 100vh
• new viewport units, eg: height: 100svh, height: 100lvh, height: 100dvh
• percent lengths, eg: height: 100%
• fixed positioned percent length, eg: position: fixed; height: 100%
• -webkit-fill-available
• window.inner-height
• environment variables, eg: env(safe-area-inset-bottom))

See examples of these at: http://smfr.org/misc/viewport-units.html

The work to be done:

1. Together, manually retest current browsers — documenting where there's interoperability & where there is not, assessing the current state of interop.
2. If anything is under specified, go to appropriate standards group & improve the specification, removing ambiguity.
3. Open issues for any implementations that don't match the standard. Browsers fix those bugs.
4. Browsers, implement new viewport units, including inline & block logical units.
5. Teach web developers new best practices.

[foolip]

Does anyone have a good grasp on the testing situation around this? I've searched for svh, lvh and dvh in web-platform-tests but can't find any existing tests.

Hopefully some of the tests in https://wpt.fyi/results/css/css-values are relevant, a bunch of them include "100vh" at least.

https://wpt.fyi/results/css/css-env spontaneously looks like too few tests to be covering env() well but I didn't look closer.

There seems to be just a single test using -webkit-fill-available, but actually testing something else. I haven't dug into innerHeight, 100% height, "resize" event timing, etc.

I think this proposal is on very solid ground when it comes to the rationale and would definitely be noticed by web developers, so I'd hate for a lack of tests today to rule it out. I'm not sure how realistic it is to flesh out the testing sufficiently in the remainder of 2021, but maybe that's doable. Alternatively, I hope we can find a structure for cross-vendor collaboration on solving this issue in 2022, even if doesn't form part of the Interop 2022 metric.

[gsnedders]

The WebKit tests for the new viewport units are Obj-C++ so that they can configure the viewport appropriately.

Certainly simply writing tests that assert the new viewport units are supported isn't too hard, nor that they are related to the UA-default viewport appropriately. Testing the dynamic behaviour isn't currently easily automatable in a cross-browser way (and regardless we aren't running tests for wpt.fyi on mobile presently which is where all the interesting dynamic functionality exists).

[foolip]

For the new viewport units, I wonder if we could have shallow automated tests, but also write manual tests for things like the behavior when the address bar gets hidden on scroll.

In parallel we could work out what automation would be required for these tests, and maybe automate them for an Interop 2023 metric.

[jensimmons]

I might suggest we think of this project in distinct parts, some of which should be included & some of which should not:

1. Include the new units and anything else that’s already well-specified in Interop 2022. Create/collect tests as best we can. (Definitely do this. This is the MVP.)

2. Research the current state of implementations in browsers. Document what’s found. This document could be a resource for various working groups to reference as they understand what else they could do to improve this area. Primary goal: document current state. Secondary goal: file bug tickets where browsers are different than the existing specs.

3. Make a clear list of what’s specified where regarding viewport sizing — highlighting how these interact, and where there is confusion or underspecification.

4. Drive spec works that’s needed. (Definitely do not do this. Spec work is outside the scope of Interop 2022.)

[foolip]

Include the new units and anything else that’s already well-specified in Interop 2022. Create/collect tests as best we can.

Looking for some vh tests, https://wpt.fyi/results/css/css-values/viewport-units-css2-001.html is the only one that reveals any difference between browsers. However, I think we could still include all the ones starting with vh* or viewport* in https://wpt.fyi/results/css/css-values.

@jensimmons what kinds of tests would you be looking for when it comes to "percent lengths, eg: height: 100%"? In https://wpt.fyi/results/css/css-values there are a bunch of tests with "percent" in the name, but none of those contain "height: 100%". Plenty of other tests (in other directories, in particular css/CSS2/) include "height: 100%" but are any of those relevant?

[gsnedders]

So I think the concrete suggestion here is:

1. Write tests that ensure support of the new viewport units:
   • We can't, without extra test infrastructure, mutate the size of a dynamic viewport, but
   • We can ensure they are supported, and that the relationship between them is conforming: svh <= vh <= lvh, and I think svh <= dvh <= lvh also holds.
2. Write tests for other CSS values that calculate based on the ICB (though see also [css-values-4] Difference of viewport and initial containing block size w3c/csswg-drafts#5218, [css-values-4] Clarify how and when the initial containing block and visual viewport may deviate w3c/csswg-drafts#5777, and [css-values-4] viewport units vs initial containing block w3c/csswg-drafts#6453), such as height: 100% in various contexts.
   • While we might not be able to guarantee behaviour there, I think it's quite probably reasonable to assert that the ICB is equal to one of svh, vh, or lvh.

I don't think any of these are particularly much work.

[jensimmons]

Igalia said:

We’re iffy about… Viewport measurement / units, because tests are needed and the scope of the problem feels like it lacks definition.

So let me propose a clear, more narrow scope for Viewport Measurements:

1. New Viewport Units

• Implementation of the new viewport units, (short, long and dynamic / width, height, min, max, block, inline) — eg: svh, lvh, dvh; also dvb, dvi, etc.
• Simple automated tests for those units, to check parsing correctness and relative relationships between the units. More complex automated tests are likely not possible.

2. Modest cross-browser investigation into other Viewport Measurements

• If someone from two or more teams that make mobile browsers (Safari on iOS, Firefox for Android, Chrome for Android, Samsung Internet, etc) are interested — we could collectively do a project looking into the current state of viewport measurements. That group would decide how to work, and the scope of the work. The end result would simply be a few blog posts, a report or two for working groups, and most valuable — recommendations/learnings to take back to their own teams.
• I'd be happy to lead such a project, and facilitate the process.
• This group could also undertake manual testing of the new viewport units to check interop.

[foolip]

The new viewport units were accepted as part of Interop 2022 in #39. We'll now need the simple automated tests for those units. @jensimmons @gsnedders is this something that Apple could work on?

There was also support for the cross-browser investigation into other Viewport Measurements. @jensimmons given #4 (comment), is this something that you'd like to take charge of? Google would like to participate in this work.

[jensimmons]

I volunteer at Apple's rep for a cross-browser investigation into the overall state of viewport measurements, as described above. I can help organize/facilitate/chair is that's desired.

[jensimmons]

I think there's an open question whether we want to:

1. only include automated tests for the new viewport units (short, long and dynamic / width, height, min, max, block, inline — eg: svh, lvh, dvh; also dvb, dvi, etc.)
   or
2. also include automated tests for window.InnerHeight, height: 100%, the original viewport units, etc.

I've recently heard some people articulate an expectation that we are doing 1, and other people that we are doing 2.

Perhaps this depends on whether such texts can return a length value and evaluate whether/not it's correct. Or if automated tests only test if the unit is supported by the browser.

[foolip]

For my own part, I would strongly support including automated tests for all aspects of viewport measurement that we can find, so option 2. It's a fair amount of work to identify those tests, but this one at least has some failures:
https://wpt.fyi/results/css/css-values/viewport-units-css2-001.html?label=experimental&label=master&aligned

[gsnedders]

https://gist.github.com/07ca400d2e4dd01caa4a8f0c984be068 is all the existing list of files using viewport units in WPT; note there's no tests using the new viewport units. Most of the usage outside of css/css-values is rather incidental, so even if we do include the original viewport units we should probably exclude what's outside of that.

This is the current status of those tests within css/css-values.

[foolip]

In #44 we decided to only include tests for the new viewport units in the Interop 2022 metric, and work in #41 towards more tests for existing viewport measurement issues, as well as potentially testing the new units better than we can currently do in automation.

The scope of the tests here are what @gsnedders suggested in #4 (comment):

We can ensure they are supported, and that the relationship between them is conforming: svh <= vh <= lvh, and I think svh <= dvh <= lvh also holds.

The test haven't been written yet, and may not be in WPT when the RFC is updated, but this is clear enough so that we can all, as @jgraham said, imagine what those tests will look like.

[flackr]

We could probably write a single manual test where the user hides the top controls and we simultaneously test many different things (e.g. all the various CSS units and the resize event).

[gsnedders]

Current plan:

1. Check basic support, e.g. CSS.supports("width", "10dvh"); do we just want to check the values can be parsed for width rather than any other properties? (i.e., assume it’s just a valid<length> everywhere)
2. Check relationships between the different properties; we can check the vmin is the min, vmax is the max, svh <= vh <= lvh && svh <= dvh <= lvh.
3. Check behaviour when we have nested viewports (e.g., with an iframe).
4. Check that the logical properties (vb, vi) are equal to the classic ones (vh) in various situations (RTL, writing mode, etc.).

I don't know off-hand if we can actually test the interesting mobile cases using window.scroll (as I don't know whether that affects browser chrome in different browsers/platforms), because at least in principle it would be nice to have them in a form which would be automated once we eventually start running mobile browsers on upstream WPT.

[4eb0da]

This issue mainly about viewport height, units, and so on, but I've experienced several other issues about viewport.
I can create seperate issue, if you think so

Inconsistency in "zoom on input focus" behaviour

Several years ago Safari introduced new feature: zoom the page on input focus, if font-size of it is too small (even on mobile-friendly sites)
Firefox for android also worked for this recently, but it doesn't check font-size and uses other logic. I've seen zoom around 110% on focus in FF, which I think is not expected behavour
Both of them can be "fixed" with user-scalable=no, which is bad for a11y. This solution is popular on resources like stackoverflow
So all browsers requires different approach there. If you don't want this "zoom on focus" behavour and you want to be able to pinch-zoom:

Safari:
Use "user-scalable=no". Safari will ignore it and allow to pinch-zoom, but it will disable the "zoom on focus" feature

FF on android:
Use "user-scalable=no". Page will lose pinch-zoom, but it also disables "zoom on focus" feature
Hope that new solution with "touch-action: manipulation" will come soon and "user-scalable=no" can be removed

Chrome on android:
No "zoom on focus", as far as I know. Doesn't require "user-scalable=no" and the page can be pinch-zoomed as usual

Inconsistency around viewport width

Sometimes your site is not mobile-friendly, but you whant to provide better experience for tablet users,
And sometimes tablets in portrait mode have a width is around 600, which is too low for your site. It means that you cannot safely use "width=device-width"

Also there is no value like "width=max(device-width, 980)"

I cannot rembember it exactly, but I saw:

• There is a way to do it with combination of rules in some browsers, but it will behave differently in others (like set min-width on body, different values in viewport width, and so on)
• In some browsers it can't be done at all

Problems in browsers with different approaches:

• Zoom on initial page load
• Zoom on orientation change
• Page is too large on big tablets

Moreover, Safari on iPad can behave differently, than Chrome on the same iPad

As I said, I can't remember exactly all the nuances, and maybe there is a solution which I've missed, but I can do research, if someone interested in it