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

Just to clarify a point of terminology, from the linked article (which is very well put together, by the way - thanks!):

> Aside: I don't know about anyone else, but I find use of the word "initial" in "initial containing block" slightly confusing. To me, initial tends to imply that the quantity is calculated at the start (e.g. on page load) and that it is static, whereas it is very much dynamic, adapting to changes in scroll, pinch-zoom, and adapting to changes in the visual viewport size (e.g. if the browser window is rotated or resized.)

What you're describing as "Initial Containing Block" here is actually what we usually call the "Layout Viewport". The initial containing block as defined in [CSS2](https://www.w3.org/TR/CSS2/visudet.html#containing-block-details) is a layout-only concept and conceptually doesn't ever change position, even when you scroll.

The "layout viewport" isn't specified but the behavior is fairly interoperable - it is a viewport in the sense that it's position changes as the user scrolls. Its size is _by definition_ the size of the visual viewport at minimum scale. Position: fixed elements use this as their containing block - meaning they resolve percentage based sizes from this (hence, a `position: fixed; height: 100%` element will resize in response to the URL bar hiding) as well as position (`position:fixed; bottom: 0` sticks to to viewport bottom even as the URL bar hides). 

So, if I understand correctly, your proposal is the have the layout viewport and ICB always match (allowing some temporary disagreement).

Is this not just going back to the way things were when hiding and showing the URL bar would resize the ICB? We changed to a model where the ICB isn't resized since experience showed it made many common use cases for vh unusable. I don't see how this proposal addresses the concerns that led to that change in the first place.

> There are no issues with regards to backwards compatibility. Web developers do not need to change anything.

I don't think this is true. The current behavior has been in place and interoperable for the last few years at least (in addition to the problem sites we had prior to the change). Any page that, for example, sets font size based on vh will now have a UX destroying reflow on each change in scroll direction anytime the URL bar is shown/hidden.

I think what you're suggesting is that there are use cases where a page actually wants this dynamic, resizing layout viewport as the source for vh units. I believe that's true but using this as a default behavior for `vh` (introduced before mobile URL bars were around) hasn't worked in the past.

Assuming you can't build your layout on `position: fixed`, which would get that behavior (but I can imagine comes with other compromises), I would suggest something akin to (another?) `vh`-type unit that _is_ dynamic (or something like a [`vh-sizing` property](https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-543344105) that allows dynamic but defaults to the current behavior). That way authors would have to opt-in to the new and unambiguously defined behavior.

Regarding more general URL bar behavior and design in browsers - I would point out this is an extremely constrained and complex area. The URL bar is the primary security surface for mobile browsers and the most user visible piece of UI. Making changes to this is extremely difficult; much more so than how the URL bar interacts with layout and page APIs (which is merely "very" difficult).

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 December 2020 22:51:07 UTC