Re: [csswg-drafts] [scroll-animations-1] Bring back Scroll Offsets (#7575)

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:

    ```css
    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 `ScrollTimeline`s 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.

    ```css
    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`?

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

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

    ```css
    #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?



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


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

Received on Monday, 8 August 2022 07:51:52 UTC