[scroll-animations-1] Support setting start and end time on scroll timeline.

[flackr]

In the rewritten spec, AFAICT scroll timeline always animates over the entire scroll range. I think it will be relatively common for developers to want to target a specific length range. While you could technically do this by carefully constructing an element I think we should support simple cases such as animating from 0px to 200px scroll offset.

With this change, I think we could also move the read-only startTime and endTime from ViewTimeline where they are currently defined to the base ScrollTimeline interface.

[flackr]

@kevers-google FYI

[flackr]

My proposal would be to add to the scroll timeline CSS and javascript constructions a start and end offset / time. These should accept lengths, e.g.

From Javascript:

element.animate(
    {transform: ['none', 'translateY(100px)']},
    {timeline: new ScrollTimeline({
        source: scroller,
        endScrollOffset: CSS.px(100) /* Presuming we go with CSSOM types */
    })});

From CSS:

.foo {
  .animation-timeline: scroll(0 100px); /* optional axis and scroller omitted for brevity. */
}

Note, that with the ability to specify start and end scroll offsets we might need to revisit whether we want the arbitrary offsets list from #4912 or not. My preference would be to avoid the complexities of arbitrary lists of offsets for the initial spec, but if we want to prepare for that possibility we could pass an array or object structure to the JS API rather than having an explicit startScrollOffset and endScrollOffset.

[fantasai]

Some questions:

• What happens if the specified range is, or extends beyond, the possible scroll range?
• Do we have any real use cases for this? (I definitely thought it fit within the API when drafting up, but I didn't add it because I wasn't sure there were use cases that weren't better served by tying it to an element position.)

[flackr]

• What happens if the specified range is, or extends beyond, the possible scroll range?

The naive thing - you use the value as is and can't get to the full 100% progress through the timeline.

• Do we have any real use cases for this? (I definitely thought it fit within the API when drafting up, but I didn't add it because I wasn't sure there were use cases that weren't better served by tying it to an element position.)

The main case I was thinking was for header parallax cases (e.g. the header on the polyfill demo), though arguably this could be done with the proposed view-timeline-range: exit on the parallax container.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] Support setting start and end time on scroll timeline., and agreed to the following:

• RESOLVED: Close this with no change

The full IRC log of that discussion

<dael> Topic: [scroll-animations-1] Support setting start and end time on scroll timeline.
<dael> github: https://github.com//issues/7296
<dael> flackr: This is just a minor one. When create scroll timeline it always animates over full scroll range
<dael> flackr: Has been desire for devs to say animation runs one scroll offset to another. Unclear if use cases are better solved with new timelines. That's the counterargument to adding
<dael> flackr: Prop could be punt for now and add later
<smfr> q+
<Rossen_> ack fantasai
<dael> fantasai: I was on queue to basically say that I drafted it up because it would make sense but asked what would be better here then using view timeline. Can add later once there's better use cases
<dael> smfr: When you said a new timeline are you impl there's a generic feature
<dael> Rossen_: Said view timeline
<dael> smfr: Okay. Should this be a generic feature to allow you to trim ends of animation generally or is it specific to scroll
<dael> fantasai: Don't have generically b/c some timeslines don't have an end
<Rossen_> ack smfr
<dael> flackr: There is end-delay prop of animations that if applied to scroll linked allows you to trim end
<dael> fantasai: document-timeline doesn't have an end you can trip for example
<fantasai> s/trip/trim
<dael> Rossen_: smfr does that answer your question?
<dael> smfr: Not sure. This sounds like range mapping to me which may be a generic that web animations should support. I don't know enough to say if that's a sensible ask
<dael> flackr: I would say we don't have enough detail about what the ask would be here
<dael> fantasai: My prop is we close no change. If people come back with a use case that's a scroll timeline that's not to element position we can come back and add it
<dael> Rossen_: Prop: Close this with no change
<dael> Rossen_: Objections?
<dael> RESOLVED: Close this with no change

[bramus]

A bit too late perhaps, but this cover-page to fixed-header demo would be a use case? As you scroll from 0 to 90vh, the 100vh cover transforms to a header with a height of 10vh.

Looking at the exit phase of the header doesn't work, as it has position: fixed applied and therefore never slides out of the viewport.

Looking at the enter phase of #content wouldn't work either as technically #content already is intersecting the viewport from the start: because the cover is position: fixed, #content shoots up and will be entirely in view on load. To have it appear visually below the header it has top padding of 100vh.

One could argue to change the padding-top to a margin-top, so that one could observe the enter phase of #content after all. While that could work, it would break componentization: it would be nice to have this cover available as a standalone component that can work out of the box with whatever comes next. As authors drag this component from project to project, the adjacent sibling will have a different (or no) id. Forcing authors to update the CSS snippet every time they use it somewhere else feels a bit wrong.

[ydaniv]

+1, also we can say that in general, being able to create such effects for reusable components that can't rely on other elements to trigger intersection