-
Notifications
You must be signed in to change notification settings - Fork 677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-values-4] Visual viewport units #7194
Comments
I'm not much familiar with that, but I think |
The current spec for dynamic viewport units is clear:
That's why I think we need a new unit. |
I believe based on https://bokand.github.io/demo/urlbarsize.html (and inserting a <textarea> or in the DOM to trigger the keyboard behaviour) that Blink will adjust the dvh/lvh unit based on whether the keyboard is showing. @devongovett - Does Chrome Canary on Android (with chrome://flags/#enable-experimental-web-platform-features enabled) match your expected behaviour? |
I believe Chrome on Android has always resized the viewport when the keyboard appears, even with regular |
Note that this would still be true of a new viewport unit. dvh explicitly says UAs are not required to animate the unit while stuff is showing/hiding, just that they have to be correct when the animation is finished. We'd have a similar clause for any other unit in this space. |
A challenge with using a visual viewport unit to achieve these use cases is that the visual viewport also resizes (and offsets) as a result of pinch-zoom. If you're positioning a floating toolbar based just on the visual viewport height, it'll be wrong as soon as some pinch-zoom (and non-0 IMHO, something like position: device-fixed seems more natural for these use cases since it'd let you position things in the coordinate space of the visual viewport. |
That might work for fixed size floating toolbars, but I need to both position and size content to fit above the keyboard though. When the user scrolls while the keyboard is open, content shouldn't be behind the keyboard, only above it. |
A forked version that includes this can be found at https://urlbarsize.netlify.app/urlbarsize-allowresize.html
Correct. It's the only platform that does this, and we'll be looking into that as part of web-platform-tests/interop#41
What if the zoom level was also exposed? Then an author would be able to reconstruct the “Unzoomed Visual Viewport” values from that:
( Alternatively
Also a fan of it :) |
The proposed Visual Viewport Units do not form a closing solution for the stated use-case of positioning above the Virtual/On-Screen Keyboard (OSK). Take this snippet that should achieve the desired effect. #target {
position: fixed;
height: 2em;
width: 100vvw;
top: 100vvh;
transform: translateY(-100%);
} The code above only works when the top edges of the Layout Viewport and Visual Viewport line up. This, however, is not always the case. When scrolling down with the OSK shown, the Layout Viewport will initially stay where it is, and the user is merely moving the Visual Viewport down. Because the Visual Viewport always matches the device, the net result is that the Layout Viewport will “shoot up”. See illustration below where the FixedPos Element (orange) appear to be floating in the middle of the Visual Viewport (orange dotted line) once you scroll down, because it is laid out against the top edge of the Visual Viewport (blue dotted line). To work properly one would also need the distance between the top edges of both viewports mentioned, which would introduce even more extra units. The already mentioned The units proposed here would play nice together with that |
I started #7475 to discuss a particular proposal to allow content to stay visible when the keyboard is shown. It has an interactive demo that can be viewed on desktop. This seems highly related. |
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: Viewport Units<fantasai> fantasai: I think we need someone from WebKit in this discussion <fantasai> fantasai: WebKit does all kinds of fun and interesting things with the viewport on mobile <fantasai> fantasai: Do we know if they'll be dialing in later today? <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 <fantasai> github: https://github.com//issues/7194 <fantasai> bramus: Recently added viewport-relative units <fantasai> bramus: lv*/dv*/sv* <flackr> q+ <fantasai> bramus: Suggestion is to add new units for the visual viewport units vv* <fantasai> bramus: to reflect the width/height of the visual viewport <fantasai> bramus: for clear understanding this is the part you see on screen <fantasai> bramus: when you pinch zoom, this becomes a viewport on top of the canvas <fantasai> bramus: so this is a sub-viewport of the others, and it describes (?) <vmpstr> s/(?)/the part that you see/ <fantasai> flackr: I think david and bramus pointed out that if we had such units, it would cause layout changes while you zoom <fantasai> flackr: which is disruptive and also perf problems <fantasai> flackr: the fundamental use case seems to be positioning around a virtual keyboard <fantasai> flackr: so we have some alternate proposals for positioning things relative to the edge of the keyboard <Rossen_> ack flackr <fantasai> flackr: see https://github.com//issues/7475 <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 <TabAtkins> fantasai: so we can't do this, but we can try to address the concerns another way <bramus> q+ <emilio> +1 from me too fwiw <Rossen_> ack bramus <TabAtkins> +1 from me too on that <fantasai> bramus: the use case for visual viewport units is if the author wants to have an element that perfectly fits that size <fantasai> bramus: simply a use case for an element sized to fit within the space left by the keyboard <fantasai> Rossen_: Any reason why can't use the viewport offsets, that were proposed and are in css-env? <fantasai> Rossen_: we had an elaborate proposal for how to address these various sizes <fantasai> bramus: are you talking about pageLeft/pageTop and offsetLeft/offsetTop? <fantasai> Rossen_: no <fantasai> Rossen_: I'll take a second to find the actual issue <TabAtkins> fantasai: I think pinch-zoom and presence of keyboard are two very different things <TabAtkins> fantasai: keyboard-shifting makes sense to address, pinch-zoom makes sense to specifically *not* address <TabAtkins> fantasai: agree we commonly need to accommodate the keyboard somehow and should look into it <TabAtkins> fantasai: but not pinch zoom <florian> q+ <florian> q- <fantasai> bramus: should we discuss the issue flackr linked to? <fantasai> fantasai: Do we want to take a resolution to not add units that respond to pinch-zoom? <dbaron> +1 <fantasai> Rossen_: any objections? <fantasai> RESOLVED: Not adding units that trigger layout changes based on pinch-zoom <Rossen_> q? <Rossen_> ack fantasai |
Closing out since we definitely won't be adding visual viewport units, but discussion on addressing the use case should continue in #7475 (or other issues). |
The new viewport relative units introduced recently are a great step forward. However, none of them correspond with the VisualViewport API in JavaScript. Specifically, when the software keyboard is visible, the
visualViewport.height
property changes accordingly, but e.g.100dvh
does not.This behavior is problematic when trying to build interfaces that are positioned above the on-screen keyboard, or resize so that they are always visible while the keyboard is open. Examples include chat UIs, commenting UIs, trays/sheets, modals containing forms, floating toolbars, etc.
I would like to propose another unit that corresponds exactly to what the VisualViewport API returns, but without requiring JavaScript. It is possible to accomplish this by setting a custom property from JS when the VisualViewport resize event occurs, but this approach has some drawbacks:
Possible names:
vvh
- i.e. visual viewport heightvvw
vvmin
/vvmax
Has something like this been discussed in the past?
The text was updated successfully, but these errors were encountered: