- From: Botond Ballo via GitHub <sysbot+gh@w3.org>
- Date: Sat, 21 Nov 2020 19:39:29 +0000
- To: public-css-archive@w3.org
> Regarding this proposal for a new unit representing 1% of the "minimum possible" viewport size, is it a well-defined/workable/future-proof concept in general terms? I'm not sure that it is. (I've edited this to clarify concerns...) > > * How will a user agent know in advance whether the user will call up an address bar or a small or large keyboard or other control, each of which could have a different size? Does the user agent need to choose the smallest possible area based on all possible 'overlays' to be on the safe side? > > * The size of the additional UI and so remaining available space could depend on user agent/OS font sizes, zoom or accessibility settings, and so `vhc` would change if those change, shrinking if the controls expand. Is that expected/wanted behaviour? > > * What happens in future if a browser decides to let the user slide the address bar out even further to expose some other control such that the minimum size shrinks? Does that mean that any web content using `vhc` in that browser would unexpectedly look different because the minimum theoretical size has changed, even though that new control would not be visible most of the time? My understanding of the proposal is that `vhc` would be 1% of the minimum possible viewport size given the _current_ settings. So, if you change the system font size in a way that affects the height of the address bar, the page would be reflowed and `vhc` sizes recomputed. But if you just trigger hiding or showing the address bar through interactions with the page, it would not. -- GitHub Notification of comment by theres-waldo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-731626550 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 21 November 2020 19:39:31 UTC