- From: David Bokan via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Oct 2019 09:31:25 +0000
- To: public-css-archive@w3.org
I initially argued that vh should reflect the minimum possible size but didn't get a response from WebKiters so decided that the larger size and compat with Safari was preferable to a saner default but incompatibility with Safari. > Also, I guess the units people really wants is the visual viewport size instead of the layout viewport. CCing @bokand I don't think so. The visual viewport is conceptually detached from layout. i.e. if the user zooms in, the visual viewport shrinks. So we don't ever want layout to depend on visual viewport properties. I think having a new unit for the minimum possible size sounds fine, or exposing the browser chrome insets instead as @AmeliaBR mentioned (I think that's equivalent to this proposal) which might be easier to explain. > I would say that yes, any feature for adjusting to URL bar show/hide behavior should also include the keyboard and any other pop-up/pop-over browser widgets that cover part of the layout viewport. Example use case: if the UI consists mostly of a large text box, it's nice to make that fill most of the window. It's less nice if the box gets covered up by the keyboard you're using to type in it, and you end up with a scrolling text box inside a scrolling window. Chrome on Android today resizes the ICB when the keyboard comes in. I think it's a rather regrettable decision since resizing the ICB can take a long time - it's a significant source of making the mobile web feel janky. In addition, it's not uncommon to tap on an editable only for the resized layout to now obscure the box you're trying to type into. We've had success on ChromeOS using a model where the onscreen keyboard shrinks the visual viewport but leaves layout unchanged. Anecdotally this works much better: the user can still pan around the full viewport but the layout doesn't change at all when the keyboard comes up which works much better, especially on sites that didn't give much thought to onscreen keyboards. Unfortunately it's a difficult thing to bring to Android because of compat so we haven't been able to do it yet. -- GitHub Notification of comment by bokand Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-542615096 using your GitHub account
Received on Wednesday, 16 October 2019 09:31:27 UTC