[csswg-drafts] Support Cross-Origin iframe use case (#4344)

stephenmcgruer has just created a new issue for https://github.com/w3c/csswg-drafts:

== Support Cross-Origin iframe use case ==
**Note**: This assumes familiarity with issue w3c/scroll-animations#39

During a recent Origin Trial of ScrollTimeline, we received feedback from developers that a common setup for them was to have a cross-origin iframe (usually hosting an ad) that wished to animate with respect to the scroll of the main viewport. This wasn't possible for ScrollTimeline, as there is no way to set the _scrollSource_ outside of the current document.

### Proposed Solution

If we look to [IntersectionObserver](https://w3c.github.io/IntersectionObserver/), which is in a similar situation, it does this via an [implicit root](https://w3c.github.io/IntersectionObserver/#intersectionobserver-implicit-root) concept - when the _root_ is null then the 'the top-level browsing context’s document node' is used.

The equivalent change for ScrollTimeline would be to treat a null _scrollSource_ as something like 'the scrollingElement of the top-level browsing context's Document'.

**Important**: We would have to change the `scrollSource` parameter of ScrollTimeline to be the unresolved scroll source, to avoid leaking cross-origin information.

There could be security implications of this, since it provides some form of communication to the cross-origin iframe about its hosted environment (by computing the `currentTime` and observing the results); the initial expectation is that it is no worse than IntersectionObserver but this has not been scrutinized.

### Note on issue w3c/scroll-animations#39

In order to fully satisfy the cross-origin iframe ad use-case, it would also need issue w3c/scroll-animations#39 supported, as the iframe has no way to compute what its startScrollOffset/endScrollOffset should be.

The most ergonomic thing for the developer would be if they were able to target whatever element they wanted **inside their origin**, and the currentTime algorithm would take care of whatever nesting of scrollers existed between the startScrollOffset/endScrollOffset target and the resolved scroll source. A similar issue exists for the non-cross origin case, and is discussed in issue w3c/scroll-animations#39.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4344 using your GitHub account

Received on Thursday, 19 September 2019 05:42:04 UTC