Re: [csswg-drafts] [css-scroll-animations] Rethinking declarative syntax for scroll-linked animations (#6674)

As pointed out by @andruud and @flackr above I also think it's preferable to keep the JS and CSS interfaces tied to each other. Right now this is the case: if you know how one works you also know the other, as they share the same concept/approach.

---

@fantasai Regarding those "element slides into view"-animations.

Note that it can also be about a portion of that element, e.g. "only start when a quarter into view" or "be finished when 75% in view". I've done so in https://www.bram.us/2021/03/04/the-future-of-css-scroll-linked-animations-part-2/#demos--revealing-images for example where the animation runs from 50% into view to 100% into view.

Above that several animations can be attached to several phases of a timeline. See https://www.bram.us/2021/03/04/the-future-of-css-scroll-linked-animations-part-2/#demos--contact-list-revisited for example, where there are different enter and exit animations on the same element.

💡 To implement this it looks like a good idea to me to have one shared `view-timeline` for an element, and then be able to tap into parts of that `view-timeline` (e.g. the enter and exit phases) to hook animations on.

I'm thinking of two new properties here:

- `animation-timeline-phase` to define which part of the `view-timeline` you want attach your animation on.
  - Values are `enter`, `exit` and `auto` (= for the entirety of the `view-timeline`, with respect to `view-timeline-fit`)
- `animation-timeline-thresholds` to define the element-based thresholds for running the animations.
  - As an author you can opt to set two thresholds, e.g. `25% 80%`.
    - Both percentages indicate _"how much percent of the element should be in view"_. 
    - The first one is the start threshold _(e.g. how much percentage does the element need to be in view before the animation can start)_
    - The second one is the end threshold _(e.g. when the element in that much percentage in view the animation must be finished)_.
  - Default value is `auto`.
    - For `enter` phases that translates to `0% 100%` _(i.e. from element not in view and touching start edge to element entirely in view)_.
    - For `exit` phases that translates to `100% 0%` _(i.e. from element entirely in view and touch end edge to element entirely out of view)_.

The adjusted syntax for the https://www.bram.us/2021/03/04/the-future-of-css-scroll-linked-animations-part-2/#demos--contact-list-revisited example would then become:

```css
@keyframes animate-in {
   …
}

@keyframes animate-out {
   …
}

ul {
  overflow-y: scroll;
}

li {
  view-timeline: li-in-ul;
  view-timeline-fit: cover;
}

li > * {
  animation:
    animate-in 1s linear forwards,
    animate-out 1s linear forwards;
  animation-timeline: 
    li-in-ul, 
    li-in-ul;
  animation-timeline-phase: 
    enter,
    exit;
  animation-timeline-thresholds:
    25% 100%, 
    100% 25%;
}
```

In this example:

- The `animate-in` animation would run during the `enter` phase of the `li-in-ul` timeline. The animation will start when the watch element (the `li`) is 25% in view at the start edge and be finished when the watched element is entirely in view.
- The `animate-out` animation would run during the `exit` phase of the `li-in-ul` timeline. The animation will start when the watch element (the `li`) is 100% in view at the exit edge (e.g. about to leave) and be finished when the watched element is 75% out of view.

🤔 Braintwist: If these new properties would exist, is `view-timeline-fit: cover;` still feasible as we're basically delegating that responsibility to `animation-timeline-phase`? `animation-timeline-phase` could in that case be extended to accept the values `cover` and `contain`, deprecating `view-timeline-fit`.

🤔 Braintwist on the braintwist: Say`animation-timeline-phase` would be extended as suggested in the braintwist above and a user wants to do something like "run the animation from the moment the element is entering the scrollport until it is halfway in the scrollport", then the `enter`/`exit`/`cover`/`contain` keywords won't do. 

In that case I'm sliding back to a syntax using an edge and a percentage, which is awfully similar to [`<element-offset>` from the current proposal](https://drafts.csswg.org/scroll-animations-1/#typedef-element-offset):

```css
animation-timeline: some-element-in-a-scroll-container;
animation-timeline-phase-start: end 0%; /* Start animation when the watched element is sitting at the end edge, with 0% in view*/
animation-timeline-phase-end: 50%; /* Have animation be finished by the time the watched element is in the middle of the scroll-container*/
```

To combine these in the `animation-timeline-phase` shorthand a separator other than `,` would be needed.

Thinking of `/` right now (e.g. `animation-timeline-phase: end 0% / 50%;`) as using a space (e.g. `animation-timeline-phase: end 0% 50%;`) makes it somewhat weird: the first percentage is a threshold but the second percentage is a progression of the `view-timeline`.

_(Apologies for freewheeling here. My mind is playing ping-pong with itself when it comes to Scroll-Linked Animations 😅)_

---

Looking a bit broader, I think it's advised to also keep Scroll-Triggered Animations in mind while figuring out the syntax for Scroll-Linked Animations, so that we don't hit a wall when they are being considered. I'm seeing options with something like `animation-timeline-type: trigger` here, also being to leverage the proposed `animation-timeline-phase` if need be.

-- 
GitHub Notification of comment by bramus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6674#issuecomment-930542414 using your GitHub account


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

Received on Wednesday, 29 September 2021 21:04:36 UTC