- From: Johannes Odland via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Mar 2021 09:59:26 +0000
- To: public-css-archive@w3.org
@brunoais I think our interpretations are definitely different. This PR specs a vhc unit as folows: > **vhc unit** When user agent chrome does not change size, it is equal to 1% of the height of the initial containing block. When user agent chrome does change size, it is equal to 1% of the height of the initial containing block with the user agent chrome at its largest size. As I interpret it it, this viewport unit is defined relative to the ICB and will only change when a window is resized and the ICB changes size. It is stable and does not change when UA chrome changes size. (It will be 635px on the iPhone in my example, as long as the phone is not rotated.) If the unit changed with the UA chrome we would get all the reflow issues that we had with vh earlier. Having this unit in addition to vh is very useful, at least for us. It allows us to use css to style content that fits inside the browser chrome without using JS. Viewport units matching the visual viewport could be useful too as a way to reference the [visual viewport API](https://wicg.github.io/visual-viewport/index.html) values in CSS, but as I read the original issue and the PR this unit is defined relative to the ICB. -- GitHub Notification of comment by johannesodland Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5108#issuecomment-800952595 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 March 2021 09:59:31 UTC