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

mind-bending-forks has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values-4] Clarify how and when the initial containing block and visual viewport may deviate ==
# Background

This proposal is supported by the following article:
https://mind-bending-forks.github.io/css-viewport-percentage-length-units/

Mobile browsers implement a toolbar hiding/revealing feature that results in the visual viewport changing size and position. Having a dynamically resizing initial containing block may lead to unsightly reflow, and so current design avoids this. An inevitable consequence is that the initial containing block deviates from the visual viewport in the initial un-zoomed state (zero pinch-zoom), and this results in content that would ordinarily be visible being truncated while the toolbars are in view.

An issue arises because of the way the hide/reveal mechanism has been linked to scrolling of the underlying content. There are certain situations, such as when using viewport-percentage length units to create content that fills the viewport and when the content contains sub-regions that are scrollable, where the toolbars (and so truncated content) persist. In the problem cases, this truncation persists indefinitely, or until a user scrolls/swipes the outermost content, and so only *if* they scroll/swipe the outermost content, and so only *if they can* scroll/swipe the outermost content (which is not currently always the case).

This proposal seeks to place limitations on content truncation by clarifying that the initial containing block and visual viewport are permitted to deviate, but only briefly/temporarily and for a specific action/purpose, otherwise the initial containing block should be re-aligned with the visual viewport. 

This therefore provides guidance to browser developers that may encourage modifications to current design that address or minimise the issues identified above. My hope is that problems with truncation of content currently marked as [wont fix](https://bugzilla.mozilla.org/show_bug.cgi?id=1677412) will at some point be changed to "let's see what we can do to improve matters" at least.

# Proposal

The proposal is for the following text (or some variation on it) to be included in the CSS specification, probably alongside the definition of the initial containing block - which is currently defined at https://www.w3.org/TR/CSS21/visudet.html#containing-block-details:

> At zero pinch-zoom, the user agent may allow the initial containing block (ICB) and visual viewport to diverge (e.g. by overlaying or shifting the ICB), provided that the change is:</p>
>           
> - 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
> - 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.
>   
> Any other change must result in a realignment of the ICB with the visual viewport and a corresponding change of viewport-percentage length units.

# Advantages

- There are no issues with regards to backwards compatibility. Web developers do not need to change anything.
- The proposal is general, and applies equally well to desktop and mobile environments, and covers toolbars, keyboards and other UI/browser chrome that may overlay the viewport.

# Drawbacks

- It might take some time for mobile browser design to be improved. An interim solution might be needed.
- This proposal might not be sufficient for some web developers, who may wish to position content relative to the toolbars/keyboard etc., even if only temporarily in view.

The drawbacks could be overcome by introducing *visual-viewport-percentage units* (`vvh`, `vvw`) that are calculated relative to the instantaneous visual viewport size. It would then be the responsibility of the web developers to check how well their particular usage of visual-viewport-percentage units works.

# Alternative Proposals

- [Add vhc value](https://github.com/w3c/csswg-drafts/issues/4329)
- Visual-viewport-percentage units (Just an idea. Not yet formally submitted.)

# Current Workarounds

- Use javascript to detect the viewport size and adjust layout accordingly.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5777 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 11:11:56 UTC