[cssom-view] elementFromPoint etc need to be defined in terms of layout and visual viewports

[smfr]

https://www.w3.org/TR/cssom-view-1/#dom-document-elementfrompoint

elementFromPoint(), elementsFromPoint() and caretPositionFromPoint() need to define whether the arguments are relative to the layout or visual viewports. Other "client" coordinates are being defined as being in terms of the layout viewport (e.g. getBoundingClientRects(), getClientRects(), event.clientX/y [citation needed]).

The spec also needs to define whether the clipping to the the viewport uses the layout or visual viewports for clipping.

[smfr]

FYI @RByers

[RByers]

This is a specific instance of the broader problem described in #505.

[emilio]

@smfr @RByers do you know what do WebKit and Blink do here? Gecko uses the layout viewport, afaict, and I think it does make sense to use the same client coordinates in this case.

I'm considering helping a bit and extending these APIs and it'd be great to resolve pre-existing issues with them.

[bokand]

I've tried to document what Blink and Edge did for every API possibly related to viewports, see this sheet

the *FromPoint APIs in Blink all take their arguments in layout-relative coordinates and clip to the layout viewport.

[emilio]

Thanks @bokand, I think there's interop here, and I expect Blink inherited that from WebKit, so probably worth just specifying they use the layout viewport.

[bokand]

Actually - the viewport split came after the WebKit fork so the implementations are independent. I had discussed these in the past with @smfr so I think elementFromPoint and friends are layout-relative in WebKit IIRC. As I recall, the point of difference was scroll-related properties like scrollX|Y|To, etc. In Blink they refer and mutate the layout viewport only but in WebKit they're the visual viewport.

[smfr]

WebKit would like to move to the layoutViewport for scrollX/Y etc, if it's web-compatible.

[bokand]

FWIW: Chrome made this change in M61 (see crbug.com/489206 - merged a bunch of bugs into that one that were fixed by this change).

There were some complaints about this at the time (e.g. general feedback collected in crbug.com/571297 and crbug.com/767388 after we added window.visualViewport) but they seemed more based on principle than practical breakage. I recall seeing a handful of specific bugs filed but they were generally of the "behavior changed" variety - I don't remember seeing anything where a page was actually broken or significantly affected.

IMHO, this actually went smoother than expected in terms of web-compat so I expect this should be doable in other engines as well.