Re: [csswg-drafts] [css-values-4] Visual viewport units (#7194)

The CSS Working Group just discussed `Viewport Units`, and agreed to the following:

* `RESOLVED: Not adding units that trigger layout changes based on pinch-zoom`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Viewport Units<br>
&lt;fantasai> fantasai: I think we need someone from WebKit in this discussion<br>
&lt;fantasai> fantasai: WebKit does all kinds of fun and interesting things with the viewport on mobile<br>
&lt;fantasai> fantasai: Do we know if they'll be dialing in later today?<br>
&lt;Rossen_> Rossen: I'm happy to defer. Also I would prefer to make progress here and now since we have enough people to discuss and come to a proposed resolution<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/7194<br>
&lt;fantasai> bramus: Recently added viewport-relative units<br>
&lt;fantasai> bramus: lv*/dv*/sv*<br>
&lt;flackr> q+<br>
&lt;fantasai> bramus: Suggestion is to add new units for the visual viewport units vv*<br>
&lt;fantasai> bramus: to reflect the width/height of the visual viewport<br>
&lt;fantasai> bramus: for clear understanding this is the part you see on screen<br>
&lt;fantasai> bramus: when you pinch zoom, this becomes a viewport on top of the canvas<br>
&lt;fantasai> bramus: so this is a sub-viewport of the others, and it describes (?)<br>
&lt;vmpstr> s/(?)/the part that you see/<br>
&lt;fantasai> flackr: I think david and bramus pointed out that if we had such units, it would cause layout changes while you zoom<br>
&lt;fantasai> flackr: which is disruptive and also perf problems<br>
&lt;fantasai> flackr: the fundamental use case seems to be positioning around a virtual keyboard<br>
&lt;fantasai> flackr: so we have some alternate proposals for positioning things relative to the edge of the keyboard<br>
&lt;Rossen_> ack flackr<br>
&lt;fantasai> flackr: see https://github.com/w3c/csswg-drafts/issues/7475<br>
&lt;TabAtkins> fantasai: I think robert's point that pinch-zoom isn't supposed to make layout changes (since you're trying to see something more clealry that's already laid out) is a really important point<br>
&lt;TabAtkins> fantasai: so we can't do this, but we can try to address the concerns another way<br>
&lt;bramus> q+<br>
&lt;emilio> +1 from me too fwiw<br>
&lt;Rossen_> ack bramus<br>
&lt;TabAtkins> +1 from me too on that<br>
&lt;fantasai> bramus: the use case for visual viewport units is if the author wants to have an element that perfectly fits that size<br>
&lt;fantasai> bramus: simply a use case for an element sized to fit within the space left by the keyboard<br>
&lt;fantasai> Rossen_: Any reason why can't use the viewport offsets, that were proposed and are in css-env?<br>
&lt;fantasai> Rossen_: we had an elaborate proposal for how to address these various sizes<br>
&lt;fantasai> bramus: are you talking about pageLeft/pageTop and offsetLeft/offsetTop?<br>
&lt;fantasai> Rossen_: no<br>
&lt;fantasai> Rossen_: I'll take a second to find the actual issue<br>
&lt;TabAtkins> fantasai: I think pinch-zoom and presence of keyboard are two very different things<br>
&lt;TabAtkins> fantasai: keyboard-shifting makes sense to address, pinch-zoom makes sense to specifically *not* address<br>
&lt;TabAtkins> fantasai: agree we commonly need to accommodate the keyboard somehow and should look into it<br>
&lt;TabAtkins> fantasai: but not pinch zoom<br>
&lt;florian> q+<br>
&lt;florian> q-<br>
&lt;fantasai> bramus: should we discuss the issue flackr linked to?<br>
&lt;fantasai> fantasai: Do we want to take a resolution to not add units that respond to pinch-zoom?<br>
&lt;dbaron> +1<br>
&lt;fantasai> Rossen_: any objections?<br>
&lt;fantasai> RESOLVED: Not adding units that trigger layout changes based on pinch-zoom<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack fantasai<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7194#issuecomment-1204282035 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 3 August 2022 17:45:56 UTC