[scroll-animations-1] Support scroll-padding in @scroll-timeline

[johannesodland]

In scroll-animations-1 element offsets are currently calculated by aligning target elements to the source scrollport.

Can we calculate element offsets by aligning them to the optimal viewing region defined by scroll-padding in stead?

Motivation

scroll-padding was introduced in css-scroll-snap-1 and specifies offsets that define the optimal viewing region of a scrollport.

In most cases the optimal viewing region is the same as the scrollport, but scroll-padding reduces the region of the scrollport that is considered viewable. When using css-scroll-snap the elements will snap against this region, and not the scrollport.

If we define scroll-timelines against the optimal viewing region we can start and end animations when they enter the optimal viewing area.

Why use the optimal viewing area

Authors need control over when an animation starts and ends so that the animation is played when it's viewable and not distractive to the user. The current spec makes it possible to start and end the animation based on when a target element enters and leaves the scrollport. This might not be enough and does not align with specs like scroll-snap.

There are many reasons authors might define an optimal viewing area for an animation:

1. Only animate when visible
A target entering the viewport might not be visible to the user. Elements such as headers and footers might be covering up parts of the scroll-port.

2. Avoid distracting the user
Usability testing might show that users are reading the text one part of the screen, and animations should not start until they enter this area so that the user isn't distracted.

3. Choreograph the animation with scroll-snap and scrollIntoView()
The authors need to choreograph the animations so that they start or end when elements snap into place or are scrolled into view.

Why not wait until level 2?

Once scroll-animations-1 is adopted it would be too late to align scroll animations with the optimal viewing region as this would change existing animations and break the web. It would be necessary to define a new property along the lines of box-sizing, or a new property such as source-padding.

[majido]

• @flackr @ogerchikov who can speak more on this.

I think using the container's scroll port adjusted by scroll padding is the better options instead of just container's scroll port. That is most likely what authors want if they are adding a scroll-padding.

While it is possible to mimic some of this with threshold but that is awkward.

[johannesodland]

It's possible to mimic this only when scroll container dimensions are available. That is when the scroll container is the root element. Otherwise I don't think it's possible.

Any chance of getting this in scroll-animations-1?

[johannesodland]

Will be fixed by view-timeline-inset in the new syntax proposal: #6674

[flackr]

We resolved on a view-timeline-inset of auto resolving to the scroll padding, and being able to specify an alternate inset if desired in #7243. I believe this addresses the needs raised here.