Where should the 'viewport' object go?

[bokand]

Our proposal currently has the viewport object on document.documentElement. This may not be the ideal place for it.

[bokand]

@esprehn wrote on the blink-dev discussion:

"Any element can be the documentElement, that means you're extending the global interface to have a concept of viewport which doesn't seem right. Having this property on thousands of elements but only ever non-null on a single one per page (for the lifetime of the page) is very strange. Especially since if I remove the documentElement there still is a viewport."

Yah, the way that everything works today that is strange. As Rick mentioned, it's not clear that we'd ever want to pursue something like -ms-content-zooming but we don't want to close that avenue either.

Suppose we'd put this on window.viewport and later we wanted to give elements the ability to zoom independently (and thus have independent viewports), could we do something similar to how documentElement.scrollTop delegates to window.scrollY or is that a wart that we'd rather not replicate? E.g. if we added Element.viewport we'd define it for the documentElement as delegating to window.viewport.

• @rbyers

[RByers]

That's one option. Another is to say that top-level viewport is NEVER controlled via an element, so even if we added Element.viewport in the future, documentElement.viewport would always be null.

Note that we probably want to avoid adding properties to window since that often conflicts with variables in use by apps. I'd suggest instead navigator or document (perhaps depending on the precise behavior within iframes).

[bokand]

In that case, I think document makes the most sense sense since content embedded in an iframe shouldn't see the same visual viewport as the parent.

For example: if you use this to build position: device-fixed, like in the example I gave, having the viewport on document means an iframe has its own viewport which doesn't change when the page is scaled so you get the expected behavior.

• @ymalik, @esprehn, does this sound ok?

[ymalik]

Having viewport on document sgtm.

[esprehn]

document.viewport seems fine.

[bokand]

I've changed to window.visualViewport. The feedback we've gotten from some web devs is that this seems more natural. The original objection was that this might conflict with existing variables named visualViewport since it's in the global scope but I did a search through httparchive and found no uses of visualViewport as a variable at all so I think this should be fine.

[RByers]

Even if some site does do var visualViewport = ... or window.visualViewport = ..., that'll continue to work fine (hiding our API) unless the same page is also trying to use our API elsewhere, right? I agree (given the HTTPArchive data) that the risk should be very low.

[bokand]

Right, existing usages should be fine unless they're doing something like checking if visualViewport is defined but the risk should be negligible.