Re: [csswg-drafts] [css-viewport] Help me bikeshed "layout viewport" (#4819)

in [5.1.2. Viewport-percentage Lengths: the vw, vh, vmin, vmax units](https://www.w3.org/TR/css-values-3/#viewport-relative-lengths)

> The viewport-percentage lengths are relative to the size of the **initial containing block**. When the height or width of the initial containing block is changed, they are scaled accordingly. However, any scrollbars are assumed not to exist.

in [the viewport](https://drafts.csswg.org/css2/#viewport)

> User agents for continuous media generally offer users a viewport
(**a window or other viewing area on the screen**) through which users consult a document. User agents may change the document’s layout when the viewport is resized (see the initial containing block).
> 
> When the viewport is smaller than the **area of the canvas** on which the document is rendered, the user agent should offer a scrolling mechanism.
> 
> There is at most **one viewport per canvas**, but user agents may render to more than one canvas (i.e., provide different views of the same document).

ok let's see what is said about canvas.

[the canvas](https://drafts.csswg.org/css2/#canvas)

> For all media, the term canvas describes "**the space where the formatting structure is rendered.**" The **canvas is infinite for each dimension of the space**, but rendering generally occurs within a finite region of the canvas, established by the user agent according to the target medium. For instance, user agents rendering to a screen generally impose a minimum width and choose an initial width based on the dimensions of the viewport. User agents rendering to a page generally impose width and height constraints. Aural user agents may impose limits in audio space, but not in time. 

And [initial containing block](https://drafts.csswg.org/css2/#containing-block-details)

> The containing block in which the **root element** lives is a rectangle called the **initial containing block**
. For continuous media, it has the **dimensions of the viewport and is anchored at the canvas origin**;

and

> If the element has 'position: fixed', the containing block is established by the viewport in the case of continuous media or the page area in the case of paged media. 

and in [10.3.7. Absolutely positioned, non-replaced elements](https://drafts.csswg.org/css2/#abs-non-replaced-width).

> For the purposes of calculating the static position, the containing block of fixed positioned elements is the initial containing block instead of the viewport, and all scrollable boxes should be assumed to be scrolled to their origin. 



There is also the [Visual Viewport API](https://wicg.github.io/visual-viewport/) by @bokand The intro says:

>  Some user agents have **split their viewport into two conceptual viewports, colloquially known as the visual and layout viewports**. This separation is useful in enabling a user agent (UA) with a small screen to allow the user to zoom in on parts of the page without causing the page to respond, for example, by obscuring the user's view with position: fixed elements. As another example, mobile UAs often provide an on-screen keyboard (OSK) for user input. Without the visual/layout split, a position: fixed element would be pushed up when the OSK is shown, obscuring the user's view. Informally, the layout viewport is what the web page uses when laying out its UI while the visual viewport is the box on the page that the user can currently see, accounting for transient UI features like pinch-zoom and the OSK. 
> 
> The existing APIs provided by UAs are **ambiguous about which viewport they're relative to**. For example, **document.scrollingElement.scrollLeft returns the scroll position of the visual viewport** while **document.scrollingElement.clientWidth returns the width of the layout viewport**. getBoundingClientRect returns the rect relative to the layout viewport while positioning non-fixed elements relative to the layout viewport is difficult. This makes building UI that responds to scrolls across mobile and desktop UAs difficult. Worse still, there's no way for the developer to be notified when the visual viewport changes. For example, the only way to know when the user has zoomed is to poll or listen to touch events and continually check window.innerWidth. 
> 
>  The Visual Viewport API is designed to provide an explicit mechanism for developers to query and potentially modify the properties of the visual viewport. It also introduces events that allow the page to listen for changes in the visual viewport, allowing UX that explicitly wants to react to these changes to do so. For example, the page could keep a small text-formatting bar above the OSK. 

in [3.2 The VisualViewport interface](https://wicg.github.io/visual-viewport/#the-visualviewport-interface)

> A VisualViewport object represents the visual viewport for a window's browsing context. Each window on a page will have a unique VisualViewport object. This object represents the properties of the window's associated Document's browsing context when that Document is fully active. 



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


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

Received on Tuesday, 18 August 2020 00:20:30 UTC