Re: [w3ctag/spec-reviews] Review window.visualViewport API (#128)

Thanks! Re: privacy review, I can't think of how it might affect privacy
but I don't have enough experience to really know. FWIW, all these values
can be (roughly) calculated already, albeit with terrible hacks and some UA
checks. You can look at some of the madness in the polyfill
<https://github.com/WICG/ViewportAPI/blob/master/polyfill/visualViewport.js>
at how they can be calculated today (Still trying to make it work in iOS
Safari).

Another thing worth mentioning, this fits in the larger question of
coordinate spaces. Edge/IE moved to the model of having a separate viewport
for layout/visual and tried to make pinch-zoom mostly invisible to the
page. However, for compatibility, they left some properties responsive to
pinch-zoom. Chrome matched Edge's semantics. This leaves us in a position
where getBoundingClientRect and event client coordinates are relative to
the layout viewport while window.scrollX/Y and window.innerWidth/Height
report the values of the visual viewport. This leads to bugs as seen in the
duplicates of crbug.com/489206. In Safari, all these APIs are relative to
the visual viewport.

We tried to remedy the situation in crbug.com/571297, shipping the solution
for a full milestone in M48 which made scrollX/Y and innerWidth/Height
relative to the layout viewport and made pinch-zoom totally invisible to
script. We didn't see any reports of broken content but got significant
developer push back since they could no longer reason about the
pinch-zoomed state without an additional API. We undid that change and it
was part of our motivation for prioritizing this API.

IMO, we'd still like to move in the direction of making pinch-zoom (and
other features affecting the visual viewport, like the on screen keyboard
on some platforms) invisible to the existing API surface. This has the nice
property that these actions don't inadvertently cause the page to change.
e.g. User zooms in to see some item on the page but the script keeps an
overlay plastered to the screen obscuring the intended item. This is
especially useful since most development still takes place on desktop
devices using emulation where these issues don't come up as readily. With
this API, if a page really wants to do something on these actions it has to
be explicit about it. The alternative is to make all the APIs relative to
the visual viewport but this has the down side of being easier to build
surprising/broken UX.

Sorry for the wall-of-text, just wanted to give some background.

Thanks,
David


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/128#issuecomment-239200501