[scroll-animations-1] Bring back Scroll Offsets

[bramus]

One of the things that did not make it into the scroll-animations rewrite is the ability to animate as a scroller scrolls for a fixed distance. This used to be covered by the scroll-offsets.

There are some use-cases, such as this cover page that transforms to a header bar as you scroll over a distance of 90vh.

One could use use a ViewTimeline here, but not on the cover/header element itself because it is sticky and therefore never exits. Instead, one would have to look at the succeeding element.

This, however, is only possible if all of these apply:

1. There is a succeeding element
2. That succeeding element is not in view at the start of the animations, so you can watch it enter
3. The ViewTimeline can be seen by the preceding header

The first 2 conditions might not always be the case, but the author could work around that if they rearrange some things in their markup. The 3rd condition is not possible, since we decided in #7047 to have “timeline search look at preceding siblings and ancestors”.

Therefore I think we should reintroduce the Scroll Offsets.

[ydaniv]

Isn't it what we have ScrollTimeline for? Isn't that simply a use-case for that?
Or, if the author prefers using ViewTimeline, then it makes sense they have a revealing element that holds the timeline, and the header is simply the target of the animation. Which should be straightforward using the current API, or did I miss something and it's not?

[ydaniv]

Ok, just checked and we did lose that ability on SctollTimeline. We definitely need to have offset and duration defined by <length>s, same as ViewTimeline can define those using phases.
So @bramus I guess this was the intention here?

[bramus]

I’ve given this some thought over the weekend, and could think of a few possible scenarios to tackle this:

1. Bring back the old scroll-offsets as scroll-timeline-offsets

   This seems like a straightforward thing, but is too limiting. For example:

   body {
     scroll-timeline: body-tl block;
     scroll-timeline-offsets: 0 90vh; /* 👈 */
   }
   
   @keyframes shrink {
     from { height: 100vh; }
     to { height: 10vh; }
   }
   
   #coverheader {
     position: sticky;
     top: 0;
     animation-name: shrink;
     animation-timeline: body-tl;
   }

   By defining the offsets on the ScrollTimeline itself, the entire ScrollTimeline is limited to the range 0 - 90vh. What if the authors want to animate on scroll outside of that range (e.g. from 90vh to 100%)? This is not possible with this approach, unless authors are able to define multiple ScrollTimelines on the same element.

2. Allow scroll as a (faux) phase with <length-percentage>

   Following the way ViewTimeline phases are defined, a scroll phase could be introduced. That way there still is 1 set of keyframes and 1 ScrollTimeline. In the keyframes, authors can target several parts of the timeline by prefixing that phase to the keyframe offsets.

   body {
     scroll-timeline: body-tl block;
   }
   
   @keyframes shrink {
     scroll 0 { height: 100vh; }  /* 👈 */
     scroll 90vh { height: 10vh; }  /* 👈 */
   }
   
   #coverheader {
     position: sticky;
     top: 0;
     animation-name: shrink;
     animation-timeline: body-tl;
   }

   Authors would need to explicitly target the (faux) scroll phase if they want to use it with a ScrollTimeline. Instead of accepting only <percentage>s as the keyframe offset, <length>s would now also be valid here.

   One of the cool things about the whole scroll-linked animations concept is that you can use regular keyframes without needing to target any phase. If wanted, maybe, it could be so that “no phase implies the scroll phase” when used with a ScrollTimeline?

   @keyframes shrink {
     0 { height: 100vh; } /* When used linked to a ScrollTimeline, this would imply the scroll phase */
     90vh { height: 10vh; } /* When used with a DocumentTimeline animation, this would be invalid as it’s no <length> */
   }

3. Introduce animation-timeline offsets

   A third option would be to introduce the scroll-offsets on the animation-timeline level. There would be two properties: animation-timeline-start and animation-timeline-end, with a <length-percentage> as their allowed value.

   body {
     scroll-timeline: body-tl block;
   }
   
   @keyframes shrink {
     from { height: 100vh; }
     to { height: 10vh; }
   }
   
   #coverheader {
     position: sticky;
     top: 0;
     animation-name: shrink;
     animation-timeline: body-tl;
     animation-timeline-offsets: 0 90vh;  /* 👈 */
   }

   This approach keeps the ability to define 1 ScrollTimeline on a an element and also to target parts of it when linking an animation. However, authors would need to attach two animations/keyframes when targeting various offsets.

   #coverheader {
     animation-name: shrink, otheranimation;  /* 👈 */
     animation-timeline: body-tl, body-tl;  /* 👈 */
     animation-timeline-offsets: 0 90vh, 90vh 100%;  /* 👈 */
   }

   One of the key things that ViewTimeline introduced, was the ability for authors to define 1 set of keyframes which can target all different phases if needed. This approach with animation-timeline-offsets does not offer this.

4. Something else?

[flackr]

This feels very similar to issue #7296 though I like some of the suggestions to handle this in a way similar to the way enter/exit phases are handled for ViewTimeline (See #7044). Following that thread, I think rather than offsets we could use whatever we decide the new shorthand for specifying start and end delay to set the range of the animation, e.g.

#coverheader {
  animation-delay: 0 90vh, 90vh 100%; /* Same as setting startDelay to 0 and 90vh respectively and endDelay to 90vh and 0 respectively. */
}

[ydaniv]

Yes, since we already decided, at least for now, that these are properties of the animation, and not of the timeline. So these should go, as @flackr said above, on the animation property as startDelay and duration/endDelay.

Though this still makes @bramus's no. 2 suggestion valid, at least conceptually, with regard to the @keyframes extension.

[bramus]

The extra added phase would leave the path for future additions open. Say a HoverTimeline were to be added, then it’s only a matter of adding a hover phase.

When no explicit phase is defined in the keyframes, the phase could be implied from the usage: adding non-phased keyframes to a ScrollTimeline? Use those “regular” keyframes. Adding keyframes that have a scroll phase to a ScrollTimeline? Use those scroll keyframes, ignoring the non-phased keyframes.

[bramus]

Some authors who have been playing around with the polyfill have raised similar issues, asking about offsets no longer being available.

1. ScrollTimeline offsets are no longer respected after last update. flackr/scroll-timeline#64
2. scrollOffset not working anymore flackr/scroll-timeline#76

The recent Motion One scroll library that enables JS-based Scroll-Linked Animations also offers this ability.

As @flackr suggested above, it could be achieved by having animation-delay-start and animation-delay-end accept lengths as their value.

• animation-delay-start = [ <time> | <timeline-range-name> <percentage> | <length> ]
• animation-delay-end = [ <time> | <timeline-range-name> <percentage> | <length> ]

[flackr]

FWIW I was thinking allowing lengths or percentages for ranges would allow greater flexibility:

animation-delay: [ <time> | <timeline-range-name>? [<percentage> | <length>]]+

Then you could use calculations within ranges, e.g.

/* Starts 10px after entering until 10px before done entering. */
animation-delay: enter 10px enter calc(100% - 10px);

[bramus]

Oh yes, great tweak! I like it!

[bramus]

@fantasai Could we get input from you on this before the spec goes to FPWD? Would love to get this back in there before the spec moves forward.