W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2020

Re: [csswg-drafts] [css-values-4] Clarify how and when the initial containing block and visual viewport may deviate (#5777)

From: mind-bending-forks via GitHub <sysbot+gh@w3.org>
Date: Sat, 12 Dec 2020 00:28:32 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-743507743-1607732910-sysbot+gh@w3.org>
I can't keep up with you all. Every time I get my head around a post and am drafting a reply, another one appears!

In reply to @bokand. So things are complicated by the fact that each browser is slightly different in its implementation. That said, in summary, if you consider the simpler case where there are no hide/reveal toolbars, I *think* following appears to be true of the ICB based on what you have said:

- It is always (notionally at least) located at document origin.
- Its size is determined by the content *unless* it is overridden by the user to have either or a fixed pixel width or height or the device-width or height (=visual viewport width or height) e.g. by using a `<meta name="viewport" ... >` tag.
- If its width or height is set to be the device width or height, then that will adapt to changes in visual viewport size (e.g. through rotation).
- You say it *doesn't* ever change size in response to pinch-zoom.

Is that more-or-less correct?

It's the last bullet which is most surprising/puzzling to me. The `vh` units are currently defined to be equivalent to 1% of the ICB. When I pinch zoom on the basic [`100vh` example](https://mind-bending-forks.github.io/css-viewport-percentage-length-units/examples/100vh.html) or this additional [2nd `100vh` example](https://mind-bending-forks.github.io/css-viewport-percentage-length-units/examples/100vh-2.html), the size of the top and bottom and zones - which are each `10vh` grow, as does the `100vh` body. This must mean that `vh` is increasing as I pinch zoom, which must mean that the ICB is increasing in size as I pinch zoom. Am I missing something?

In reply to @theres-waldo I've uploaded some additional examples so you can test for yourself. There's a 

- [`100%` variant of the `100vh` basic example](https://mind-bending-forks.github.io/css-viewport-percentage-length-units/examples/100-pct.html)
- [`100%` variant of the holy-grail example](https://mind-bending-forks.github.io/css-viewport-percentage-length-units/examples/holy-grail-100-pct.html)

In my tests of these on Android, there are some issues/differences, but not with truncation of content. If anything it's the opposite:

- On Firefox Nightly for Android, 100% corresponds to the initial height of the viewport *with the address bar*. When the address bar disappears, the content doesn't resize. (There's a white zone at the bottom where the address bar was.) So, this doesn't allow you to fill the viewport, like `100vh` does. On the holy-grail example, scrolling doesn't work properly. This is a bug in Firefox that I've reported. It gets stuck and refreshes the page instead of scrolling. Pinch-zoom works as you would expect. 
- On Chrome for Android, 100% corresponds to the the initial height of the viewport *with the address bar*. Here however, the address bar persists and cannot be hidden. So, this works in the sense that the content fills the available viewport and the scrolling seems to work as it should too. Pinch-zoom works as you would expect.

I don't have an iOS device to test on right now I'm afraid.

-- 
GitHub Notification of comment by mind-bending-forks
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5777#issuecomment-743507743 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 12 December 2020 00:28:34 UTC

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