[scroll-animations-1] Unifying ScrollTimeline and ViewTimeline

[bramus]

Given the direction where authors would be able to target phases inside of keyframes I was wondering if still need ViewTimeline as a standalone concept. Can’t we re-use ScrollTimeline for it?

This animation would run from start to finish as you scroll the root scroller to the end:

@keyframes progress {
  from {
    width: 0;
  }
  to {
    width: 100%;
  }
}

#progressbar {
  animation-timeline: scroll(block, root);
  animation-name: progress;
}

Because of how the keyframes are shaped, this animation would run as the targeted subject enters/exits the scrollport of the scroller instead:

@keyframes fade-in-rotate-fade-out {
  enter 0% { opacity: 0; }
  enter 100% { opacity: 1; }
  contain 100% { rotate: 1turn; }
  exit 0% { opacity: 1; }
  exit 100% { opacity: 0; }
}

.children {
  animation-timeline: scroll(block, nearest);
  animation-name: fade-in-rotate-fade-out;
}

I.e. once the keyframes targets any of the enter/contain/cover/exit phases, the handling would automatically switch over from the current ScrollTimeline behaviour to the current ViewTimeline behaviour.

Regarding the ViewTimeline insets: These could perhaps become an extra argument on the scroll() function? Would make sense, as you already configure the scroller there.

[fantasai]

ScrollTimeline associates with a scroll container. It's not associated with any descendant element.

ViewTimeline inherits from it and is additionally associated with a containing-block descendant of that scroll container so that it can track when that element is visible. I don't see how you can take a ScrollTimeline and use it as a ViewTimeline, it doesn't know which element to track.

[bramus]

The concepts would still remain, but they would not require extra/separate properties. Based on the keyframes, the decision can be made:

• “Regular” keyframes? → ScrollTimeline behavior
• Keyframes targeting the phases? → ViewTimeline behavior

The element to animate/track is the one matched by the selector.

[css-meeting-bot]

The CSS Working Group just discussed unifying scrolltimeline and viewtimeline, and agreed to the following:

• RESOLVED: close no change

The full IRC log of that discussion

<TabAtkins> Topic: unifying scrolltimeline and viewtimeline
<TabAtkins> github:
<TabAtkins> github: https://github.com//issues/7462
<TabAtkins> bramus: given the syntax we just agreed on (also listed in the issue0
<bramus> @Keyframes fade-in-rotate-fade-out {
<bramus> enter 0% { opacity: 0; }
<bramus> enter 100% { opacity: 1; }
<bramus> contain 100% { rotate: 1turn; }
<bramus> exit 0% { opacity: 1; }
<bramus> exit 100% { opacity: 0; }
<bramus> }
<TabAtkins> )
<TabAtkins> bramus: i was wondering if we could automatically derive the meaning - what is being targeted from these keyframes
<flackr> q+
<TabAtkins> bramus: right now we have scroll-timeline to target scroller, view-timeline to target an element as it intersects the viewport, and separate css properties for these
<TabAtkins> bramus: not suggesting to merge the concepts, but maybe one set of properties that do it all and derive what's meant from the keyframes
<astearns> ack fantasai
<TabAtkins> fantasai: i dont' think this is a good idea
<TabAtkins> fantasai: they're diff concepts with diff properties, many different settings
<TabAtkins> fantasai: and an element could both establish a scroll timeline and have a veiw anmiation, etc
<TabAtkins> fantasai: if we tried to do some magical switching it'll be more confusing i think
<TabAtkins> fantasai: also switching based on wehtehr keyframes target phases isn't a good idea, maybe you want to reuse keyframes
<TabAtkins> fantasai: the way you use them shouldn't change the kind of timleine you're attaching to
<TabAtkins> bramus: i see so if you had regular parts, like from/to offsets, you could do a regular
<flackr> qq+
<TabAtkins> fantasai: the keyframes aren't meant to be targeted
<TabAtkins> fantasai: meant to be a nice general way to specify progress
<astearns> ack florian
<astearns> ack flackr
<Zakim> flackr, you wanted to react to fantasai
<astearns> ack flackr
<TabAtkins> flackr: I don't think the switch is as fundamental as you're suggesting
<TabAtkins> flackr: Mos timportant distinction is the element used as subject means something different for view and scroll timeline
<TabAtkins> flackr: Other than that, if the defualt range is the same, they're basically the same thing, and you use phase selection to target [...]
<TabAtkins> flackr: so i'm good with the idea of closing this
<TabAtkins> flackr: just wanted to point out that it's a very minor diff between the two
<TabAtkins> bramus: I'm okay with closing
<TabAtkins> RESOLVED: close no change