W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2021

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

From: Johannes Odland via GitHub <sysbot+gh@w3.org>
Date: Fri, 02 Jul 2021 05:59:58 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-872738860-1625205596-sysbot+gh@w3.org>
> @johannesodland it seems the webkit team is currently toggling the value of `safe-area-inset-bottom` based on the browser chrome being collapsed or not.
> https://twitter.com/jrigerl/status/1402042192160493569

They seem to toggle both `vh` and `safe-area-inset-bottom`. These are the values I get on the iPhone 11 Pro simulator:

**When browser chrome is floating**
100vh = 768px
env(safe-area-inset-bottom) = 112px

**When browser chrome is collapsed at bottom**
100vh = 716px
env(safe-area-inset-bottom) = 0

There are essentially three sizes here:
768px – height behind the expanded/floating interface
712px – height when interface is retracted
656px – height above the expanded/floating interface

I can se a few issues here:

**Fixed and stable**
The spec declares that the large and the small viewports are fixed and stable. This is what mobile browsers have converged on for `vh`, but Safari 15 seems to reintroduce a dynamic `vh` that toggles when UA interfaces are expanded or retracted. This might cause issues with reflow, which was the reason browsers moved to a fixed `vh` unit in the first place: https://developers.google.com/web/updates/2016/12/url-bar-resizing

**Defining the large viewport**
The spec defines the large viewport as such: _"... the large viewport size: the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be retracted. "_

The issue here is that with Safari 15 you now get the largest viewport when the UA interfaces are expanded and floating above the viewport, not when it is retracted. It's the opposite of most current mobile browsers.

**Defining the small viewport**
One of the motivations for the small viewport is apparent in the example: "An element that is sized as height: 100svh, for example, will fill the screen perfectly, _without any of its content being obscured_, when all the dynamic UI elements of the UA are shown."

The smallest area where nothing is obscured is the area above the floating interface. If `svh` maps to this area you would be sure no content is obscured. But then you would have no way to reference the area with the UA interfaces retracted. 

It could be more sensible to map `svh` to the height when the UA interfaces are retracted. This is the size that is most common when users are interacting with the page, and it also maps to `document.documentElement.clientHeigh` and `height: 100%` inside the root element. This would make content fit perfectly into the viewport when it is at it's smallest, but would not solve the "no content obscured" use case.

I think the spec might have to deal with floating UA interfaces. A also believe that is needs to address that the viewport can be at its largest when UA interfaces are visible, and the smallest when UA interfaces are retracted. This is the complete opposite of how it is in most browsers now.

GitHub Notification of comment by johannesodland
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-872738860 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 2 July 2021 06:00:00 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:38 UTC