Re: [csswg-drafts] [css-values-4] Add vhc value (#4329)

I think a clarification, whether that be here or in a separate proposal for change to the spec. would be helpful. I would propose something different to the modification that @frehner has already started drafting though. Maybe something like this at some appropriate point in the spec.:

> On occasion, the user agent may need to change the area available for the display of content. If that change is:
> * associated with the display of additional user interface required to undertake a specific action, such as a keyboard when assistance with form input is required or an address bar when the user needs to navigate or to a new location, and is also
> * temporary by design such that:
>     * the user interface only appears when required or requested by the user, and
>     * the additional user interface is removed when the user completes the action, dismisses it or undertakes an unrelated action,
> 
> then it is at the discretion of the user agent as to whether that constitutes either
> * an overlay (with no change to `vh` or `vw`), or
> * a change of the viewport area (with corresponding reduction in `vh`or `vw`).
> 
> Any other change of the area within which content is displayed must be interpreted by the user agent as a change in the viewport.

I hope that this would make it clear that the current situation on mobile browsers, whereby an address bar is present at a point when the user has not requested it causing the content to be pushed down and the viewport to be truncated at the bottom, and this state persisting until the user has scrolled right to the bottom of the scrollable content and then a bit more before the address bar finally moves out the way and full viewport finally becomes visible, is not compatible with the standard and so is not acceptable browser/user agent design: It fails the criterion that the additional user interface (address bar) is only presented when required or when requested, and it fails the criterion that it is gets out the way as soon as it is not needed any more. It means browsers will have to change the design of that feature (address bar scroll bar interaction) or keep the feature but alter (fix) `vh` to be compatible with the actual viewport again.

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. How will a user agent know in advance whether the user will call up a small address bar, or a large address bar, or a small or large keyboard or other control etc. (or nothing). In addition, surely the size of the additional UI could depend on font sizes, zoom or accessibility settings... Does the user agent need to choose the smallest possible area based on all possible 'overlays' to be on the safe side? 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 suddenly mean that any web content using `vhc` in that browser would suddenly look different because the minimum theoretical size has changed, even though that new control would not be visible most of the time?

So, if a new unit is to be added to the spec, I would suggest that it represent "1% of the maximum possible viewport size" instead, which is a much more clearly defined (and understood I think) quantity, since any user agent will place the viewport within some kind of container that has limits on its size. On desktop browsers, where users can choose to display or hide various display toolbars, status bars etc. this will be relative to the maximum viewport size they could theoretically achieve by hiding them all. The key thing is that it would scale with the user agent container/browser window, and would not change when the viewport changes size due to changes in the user agent interface, and so would be suitable for scaling fonts etc. (regardless of how browsers choose to interpret `vh`).

With the changes above (clarification and different new unit):

- the `vhmax` or "1% of the maximum possible viewport size" unit would be suitable for scaling fonts/content, and
- the `vh` unit would - once again I hope - be suitable for positioning content.

-- 
GitHub Notification of comment by mind-bending-forks
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-731476294 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 00:41:51 UTC