Parallel API for layout viewport?

[ChumpChief]

Should there be a parallel API for layout viewport?

A couple reasons this might be interesting:

1. Enables developers to move away from the ambiguous APIs altogether. Those that do will be explicitly thinking about which viewport they're interested in when consuming the API.
2. If a developer is really only interested in responding to changes to the layout viewport and not the visual viewport, the "scroll" event is noisier than needed today. It fires when the user has zoomed and is moving the visual viewport around within the layout viewport but not touching the edges of the layout viewport.

[bokand]

My preference is to make all the ambiguous APIs relative to the layout viewport. This would make window.{scrollX|scrollY|innerWidth|innerHeight} the de jure layout viewport API and make content that hasn't explicitly opted into using the visual viewport oblivious to browser UX features like pinch-zoom and on-screen keyboard. I think this would include making the "scroll" event in your second point only fire for layout viewport scrolls.

We already so some aliasing with documentElement delegating to the window object so I'm a bit worried about adding another alias like this, especially given that I'm not sure people will opt into using it ("layout viewport" is the harder of the two viewports to explain).

The other (probably separate) issue I see here is that we should be clear about how we define the layout viewport. As far as I can tell, position: fixed elements in Edge stick to the box defined by the 's width attribute (i.e. layout size). This makes "layout viewport" an accurate term. In Chrome however, our "layout viewport" would more accurately be called the "position: fixed viewport" or "minimum scale viewport". We size and position fixed elements relative to the viewport at minimum-scale, rather than the layout size. This really only causes differences in badly built legacy cases and only on mobile devices so I consider it an edge case (also, browsers are notouriously quirky in how they handle these cases), but it's something to keep in mind as we discuss spec language.

[bokand]

I may have contradicted myself a bit with my last paragraph there. Because Chrome's "layout viewport" isn't actually tied to layout, the only way to get the layout viewport size, in general, is to create a phantom position: fixed element with width/height 100% and read that with getBoundingClientRect.

On a "well behaved" web page this isn't actually needed, and even on more tricky pages I think scrollingElement.clientWidth/Height will work today but we have some experiments where this might change. e.g. make the URL bar behave more like Safari where the scrollingElement's size doesn't change with the URL bar. An explicit API might help us here.