[csswg-drafts] [scroll-animations-1] Unifying ScrollTimeline and ViewTimeline (#7462)

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

== [scroll-animations-1] Unifying ScrollTimeline and ViewTimeline ==
Given the direction where [authors would be able to target phases inside of keyframes](https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1144946715) 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:

```css
@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:

```css
@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.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 July 2022 22:25:26 UTC