deprecate Chrome's use of the term "layout viewport"

[skobes-chromium]

Chrome historically uses "layout viewport" to mean the thing that position:fixed elements are relative to.

It has some notable differences from the "initial containing block" (ICB):

• Its size is determined by the size of the visual viewport at the minimum page scale (pinch-zoom scaling factor). For example, if the minimum page scale is 0.5, the (Chrome) layout viewport will be 2x the dimensions of the ICB.
• The origin of the (Chrome) layout viewport moves in content space when the user scrolls the page. The origin of the ICB is always (0,0) in content space.
• When the browser controls hide, the (Chrome) layout viewport expands, but the ICB does not.

I think that Chrome's use of "layout viewport" is weird, because the ICB is the thing that is most closely tied to layout! Most layout operations base themselves on the ICB. Text wraps to the ICB if no container overrides its width. Setting width:100%; height:100% will give you the size of the ICB. Setting position:absolute; right:0; bottom: 0 will give you the corner of the ICB. And CSS "viewport units" (vw, vh, lvh, svh) are all based on the ICB (with adjustments for browser controls).

I have made a demo page at https://output.jsbin.com/sidatod/quiet which illustrates this weirdness. Compare the orange bar (100vh or "viewport height") with the pink box (Chrome's so-called "layout viewport") versus the blue box (ICB).

And in w3c/csswg-drafts#7475 there is a proposal to change how position:fixed elements behave when the virtual keyboard appears. The most natural way to implement this in Chrome is to change the size of the layout viewport, without affecting the ICB. But this takes the concept even further away from what one's intuitions about the term "layout viewport" would suggest.

So I propose the following:

• start using "fixed viewport" for the thing that position:fixed elements are relative to, in Chrome code, MDN, and the explainers in this repo
• avoid the term "layout viewport", or use it as a synonym for ICB going forward
• update specs to clearly distinguish these concepts, which I think they don't do today

How closely does this align with the terminology used in other browsers and the broader web ecosystem?

[bramus]

@skobes We have our terminology wrong. The Layout Viewport for example is about Position Fixed
@skobes Chrome should change the internal terminology: e.g. Layout Viewport -> Position Fixed Viewport; ICB -> Layout Viewport
@bramus beware of confusion when redefining existing terms, when redefining ICB as Layout Viewport, people won’t know whether the “Layout Viewport” in an article they encounter means the old definition or the new one.
@bramus CSSWG has recently confirmed https://drafts.csswg.org/css-viewport/ with @emilio as editor
@bramus That stuff should eventually go in there
@skobes Change seems possible. Not as difficult as converting a whole ecosystem that’s already standardised on one thing
@skobes I can take a stab at explainers to revise them
@emilio Happy to accept PRs for the new spec
@bramus Shameless plug for https://www.youtube.com/watch?v=xl9R8aTOW_I BTW, which is a talk about all the concepts we are discussing here.

[theres-waldo]

In Firefox code, we use the term "layout viewport" to describe the rect whose size determines (together with the page size) the valid range of window.scrollX and window.scrollY (which we call the "layout scroll offset", and distinguish from the "visual scroll offset" which may be different if pinch-zoomed in). In addition, this viewport rect determines the bounds within which the visual viewport can scroll (if we're pinch-zoomed in) on an overflow:hidden page.

Would I be correct to say this corresponds to Chrome's "fixed viewport"?

If so, my only observation about "fixed viewport" as a term is that it does not fully capture the role this viewport plays (since it also has the scrolling-related properties described above). However, I don't have a better suggestion for a name and agree that "layout viewport" is misleading for other reasons, so I have no objection to this change in terminology.

[skobes-chromium]

Yes, good point. Chrome also has those behaviors for window.scrollX, window.scrollY, and overflow:hidden. So the "fixed viewport" is web-exposed in more ways than just position:fixed.

[bramus]

💡 Document Viewport?

[bokand]

At first blush, I like "document viewport" - it's the intuitive "viewport" that a document is rendered into but is general enough that it doesn't tie it to any specific behavior (like "layout") which might not be fully accurate. @skobes WDYT?

Would be good to have WebKit representation too - @smfr, thoughts?

[smfr]

"document viewport" is confusing to me because it immediately makes me think that the entire document bounds are that viewport (which is how iOS used to lay out position:fixed in early versions).

[smfr]

how about "scroll viewport"? The scroll position is the top left of this viewport, right?

[bramus]

Problem with “scroll viewport” is that “the viewport” doesn’t always scroll. This is only the case when the viewport is smaller than the document’s canvas. See current spec definition:

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.

This definition also rhymes nicely with the suggested “document viewport”. Using “document viewport” essentially is not anything new – it always has been the viewport of the document – but does prevent any confusion when compared to saying just “the viewport”

[smfr]

"document viewport" is going to make me think every time whether it covers the whole document. "scroll viewport" doesn't have that issue, and matches "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."

[skobes-chromium]

I'm not a big fan of "document viewport", that also makes me think more of the ICB than the thing we're talking about. The document is the root node of the DOM tree and the ICB is the CSS box bounds of that node.

I don't like "scroll viewport" because scroll is an operation and a verb that can be applied to any viewport. I think it will be confusing to talk about. "This scroll scrolls the scroll viewport, but that scroll scrolled the visual viewport." "Wait, which viewport is scrolling?" "Is the scroll viewport scrolling now, or is the scroll viewport no longer the scrolling viewport?"

[bokand]

How about "frame viewport"? It's the viewport associated with a frame/main-frame and gets its geometry from it.

[smfr]

"frame viewport" has the same issue as "document viewport" for me ("Does it cover the entire frame?").

I don't like "scroll viewport" because scroll is an operation and a verb that can be applied to any viewport

"scrolling viewport"? "scrolled viewport"?

[bokand]

"frame viewport" has the same issue as "document viewport" for me ("Does it cover the entire frame?").

Isn't the right answer "yes" though? The "layout viewport" does cover the entire frame (inside of which a longer document is clipped and scrolled).

[smfr]

No. In a non-zoomed page, the "layout viewport" starts with the same rect as the ICB (i.e. matches the view size, smaller than the document size if the document extends outside the view, i.e. is scrollable). As you scroll, the layout viewport moves down, i.e. its top left becomes non-zero, matching the scroll position.

If you now zoom in, the layout viewport stays the same, but the visual viewport shrinks inside it. If you now pan around, the visual viewport "bumps against" the edge of the layout viewport, pushing it around (i.e. triggering web-exposed scrolling).

So the layout viewport is explicitly about scrolling. It diverges from the ICB as soon as scrolling starts, and if you're zoomed in, window.scrollY only changes when the visual viewport pushes the layout viewport around (note that WebKit doesn't work this way yet).

Client coordinates (getBoundingClientRect etc) are computed relative to the layout viewport. So the "client" coordinate system's origin is at the top left of the layout viewport. That suggests the term "client viewport" but I don't like the term "client" here since it's so vague.

[skobes-chromium]

The visual viewport is capable of "scrolling". The offset of the visual viewport from the layout viewport is its scroll position.

https://developer.mozilla.org/en-US/docs/Web/API/VisualViewport/scroll_event

The layout viewport does not have exclusive ownership of the scroll concept.

[bokand]

In my mental model zooming in scales up the content area ("the canvas") so the frame and layout viewport are scaled up together in that case.

In a non-zoomed page, the "layout viewport" starts with the same rect as the ICB

The screen shot at the top shows the case where this isn't true, at least in Chrome. Does Safari always make layout viewport match ICB size?

[bokand]

FWIW - I've always used the term "panning" for the visual viewport to distinguish it somewhat from the layout viewport's scrolling.

[smfr]

The offset of the visual viewport from the layout viewport is its scroll position

I agree that "panning" is s better way to describe the movement of the visual viewport. Visual viewport movement does not trigger window-level scroll events.

[bramus]

Canvas viewport? (Possible confusion with <canvas> though)
Main Viewport?

If we can’t reach a consensus on a preferred term here, we can always present a shortlist to present to the WG and continue discussions there.

[skobes-chromium]

I think it used to be called "outer viewport", we could also go back to that.

[bramus]

Discussed during #27. List of names to be compiled and issue to be filed at the CSSWG, asking for a better name.