A second role for the fixed viewport?

[theres-waldo]

According to the explainer, the defining role of the fixed viewport is that it is the rect that position:fixed elements attach to and get their size from.

However, it would appear that, at least in Chromium, it serves a second role as well: it defines the bounds past which you cannot scroll if the html or body element is overflow: hidden. (I'm not sure what the appropriate name / a good name for this quantity is. In Firefox codebase terminology it would be the "scroll port" of the root scrollable element.)

A few questions:

• Is the above characterization accurate?
• Are these two roles of the fixed viewport fundamentally linked?
• Given this additional role, is the name "fixed viewport" still preferable over "layout viewport" for this quantity?

[theres-waldo]

it defines the bounds past which you cannot scroll if the html or body element is overflow: hidden

And, IIUC, there is observable behaviour associated with these bounds even if the html or body element is overflow: auto or overflow: scroll: scrolling within these bounds does not trigger scroll events sent to content, while scrolling outside these bounds does. (Am I understanding that correctly?)

[bokand]

It sounds like your mental model for this is of one scroller with two viewports. It might be helpful to think of this is as two independent, nested scrollers. i.e.:

<div style="width: device-width; height: device-height; overflow: scroll" id="visual">
    <div style="width: device-width; height: device-height; transform: scale(1)" id="fixed">
        <!-- PAGE CONTENT HERE -->
    </div>
</div>

Now, Blink doesn't actually implement this using DOM and styles like this, but the internal implementation is analogous to this. The top level scroller is the visual viewport. It's always the size of the device and it's always scrollable (though it may not have overflow).

The fixed viewport is the same size but we apply the pinch-zoom scale to it as a transform. The overflow behavior on the documentElement is propagated to the #fixed <div>.

Is the above characterization accurate?

Yes

Are these two roles of the fixed viewport fundamentally linked?

I don't think it's "fundamental" in the sense that we could choose to apply overflow: hidden to the #visual scroller but attach fixed elements to the #layout scroller. But in a rational and web-compatible model, the origin of a "fixed" element and the overflow style of the documentElement should apply to the same scroller. So I don't think we'd ever separate the two concepts.

Given this additional role, is the name "fixed viewport" still preferable over "layout viewport" for this quantity?

I'm not super attached to "fixed viewport" but I have a mildly negative opinion of using "layout viewport". "fixed" seems to be pretty central to how this viewporting model works. I suppose "layout" might be less misleading if we can change Blink to always size the fixed viewport to the ICB size but it still feels to me like the connection is somewhat tenuous.

[theres-waldo]

Thanks for the details. Firefox's implementation model is indeed closer to "one scroller with two viewports", but the model of "two nested scrollers" has been helpful in reasoning about the desired behaviour.

I'm going to close this issue as my questions have been answered.