Is 100dvh clamped between 100svh and 100lvh?

[bramus]

The Dynamic Viewport is “sized with dynamic consideration of any UA interfaces that are dynamically expanded and retracted”.

As that expanded state is equal to the Small Viewport and that retracted state the Large Viewport, one could derive that the Dynamic Viewport and its units are clamped between the Small and Large Viewport Units.

In practice this is the case, except when over-pinch-zooming out in browsers that support allow this gesture (i.e. WebKit on Mobile). In those browsers, the dvh unit exceeds the lvh size.

RPReplay_Final1661174012.mov

It seems like the dvh unit here follows window.innerHeight which also grows – see #9

Should dvh be clamped? Or should we allow this, and explicitly define it as allowed?

[bramus]

We touched upon this during #4 but not in too much detail. On the one hand It does feel weird that the dvh value can become larger than the largest viewport size. On the other hand it is somewhat logical that an element with a size of 100dv would cover the whole area – as an author you do not want content to bleed out from the bottom of it.

Another way to look at it, might be that it could be expected that the page retains its aspect ratio as you pinch-zoom out. This would prevent this behavior where the Layout Viewport’s height keeps on growing as you pinch-zoom-out.

@dcrousso mentioned that there most likely has gone some design consideration behind the existing behavior on iOS. To be checked internally at Apple.

[bramus]

Just checked this on desktop Safari for comparison: there it resizes the Layout Viewport with respect to its aspect-ratio when over pinch-zooming out.

[jensimmons]

Please ask this question at the CSSWG:
https://github.com/w3c/csswg-drafts/issues

[fantasai]

Totally fine if people want to talk through these issues in a smaller group before actually flagging it for the CSSWG agenda (we do this all the time), but agree with @jensimmons that issues around clarifying the CSS specs belong in the CSSWG repo.

[bramus]

Discussed during #20. @dcrousso talked with WebKit engineers and it seems reasonable to clamp it indeed.

We need to verify this at the CSSWG.

[bramus]

Filed w3c/csswg-drafts#7764 at the CSS WG to follow up on the definition.

Additionally, this feedback on the exposed Safari behavior was submitted using the Safari Feedback Form. No confirmation of receipt was sent.

This issue is filed as a result of the Interop 2022 Viewport Investigation Effort¹. It was originally discussed at #14, with people from Apple/WebKit attending.

As shown in the video included in the issue, Safari on iOS does something weird when over pinch-zooming out: the Layout Viewport becomes very tall as the canvas becomes more narrow, and the dvh unit grows along with that.

The dvh unit should be between the svh and lvh unit. A clarficiation was also asked at the CSS WG²

Also note the behavior of Safari on Desktop mentioned in the issue.

Footnotes

1. https://github.com/web-platform-tests/interop-2022-viewport/ ↩

2. https://github.com/w3c/csswg-drafts/issues/7764 ↩