[csswg-drafts] Underserved use cases from Origin Trial (#4345)

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

== Underserved use cases from Origin Trial ==
## Background
In developing the ScrollTimeline spec over the last few months, and after discussions with developers on their experience trying out ScrollTimeline<sup>1</sup>, we have found the current spec leaves a number of scroll-related animations either hard or impossible to implement. This issue attempts to list those and suggest a possible alteration to the spec to enable the unsupported use cases.

Some (but not all) of these issues were discovered when exploring AMP's [amp-position-observer](https://www.ampproject.org/docs/reference/components/amp-position-observer) component. Additionally some of the issues were previously [mentioned](https://discourse.wicg.io/t/scroll-linked-animations/1798/2) when scroll-animations was first proposed in WICG.

## Examined Usecases

1. Non-full viewport parallax.
1. Animate an element as it becomes visible in the viewport, and as it stops being visible again (aka the 'reveal'/'unreveal' case).
    - [Example](https://output.jsbin.com/pucuyic): Fade an element in as it becomes visible in the viewport.
    - This effect could be symmetrical or asymmetrical (e.g. different animations for entering at the bottom and exiting the top).
    - One may only want to animate one side of this (e.g. as it becomes visible but not when it leaves, such as in the above example).
1. Animate an element as long as it is visible.
    - [Example](https://output.jsbin.com/qirafih): spin an element for as long as it is visible.
    - Note that this is different than use-case 2, as it implies continuing to animate whilst the element is in the viewport after it has been revealed.
    - Note that here we are assuming that the animation is still scroll-bound. One could consider a time-bound animation, which then implies the need for 'scroll triggers'.

## Underlying Problem

The common problem shared between these usecases is that they don't want to animate based on the absolute scroll position, but instead based on the location of an element within the scroller. Most commonly this is 'when the element is visible in the scroller viewport' and the element in question is usually the one which is being animated and the scroller is usually the document viewport.

As an example, see [this gif](https://user-images.githubusercontent.com/2099009/29105493-e22a6500-7c82-11e7-9f5e-95c33c76f362.gif). The animation only starts when the entirety of the clock is inside the viewport, and it finishes the animation as it reaches the point where any part of the clock leaves the viewport.

### Why can't the developer calculate startScrollOffset manually?
It may seem like a developer can just do something like the following:
```
var startScrollOffset = target.getBoundingClientRect().y - scroller.getBoundingClientRect().y;
```
However, this has a number of problems:
- It puts the onus on devs which make it more likely that they won’t do the right thing<sup>2</sup>.  Also requiring `getBoundingClientRect` usage can cause layout thrashing if not careful.
 - Zooming. This changes layout and might change where the element is, and the web developer cannot detect it.
- Anything else that affects layout, e.g. new content added to the page. Again, the web developer may not be able to detect it - and even if they can the browser is often better placed to do the right thing.
    - Also, even if the developer can detect it, startScrollOffset is immutable so they need to reconstruct an entire timeline!

<sup>1</sup>: Via the AnimationWorklet [origin trial](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/AZ-PYPMS7EA/DEqbe2u5BQAJ); however their thoughts on ScrollTimeline were agnostic to using AnimationWorklet.

<sup>2</sup>: For example, scroll snap points moved away from an "offset model" to a "box alignment model" because of similar issues.


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

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