Re: [csswg-drafts] [scroll-animations-1] Phases for taller than scrollport subjects (#7973)

> The enter/exit phases are defined not based on "am I crossing a threshold", but rather "am I in the process of entering the viewport" where the state of having entered is the "contain" phase.
> 
> And the "contain" phase is not defined as "fully contained by the viewport" for large items because this would mean such items would never reach the contain phase. We could rename it, but basically the "contain" phase as it's defined now is the "I'm fully in the viewport (inasmuch as I can be)" phase.

Thanks for clarifying the definitions. I think `contain` could be renamed, but the only fitting name I found for it is `cover`: _“I am covering the viewport (inasmuch as I can)”_. Unfortunately it’s already used, so would require a rename of the existing `cover`.

> Are there use cases for other phase interpretations? Yes. Should we find ways to enable them? Probably.

What is we allowed authors to define custom animation phases? Something like:

```css
@custom-timeline-phase --long-exit {
    from: start start 1; /* When the start edge of the subject hits the start edge of the scroller, and the subject is 100% (or more in case of taller-than-scrollport-subjects) in-scrollport. */
    to: end start 0;  /* When the end edge of the subject hits the start edge of the scroller, and the subject is 0% in-scrollport. */
}
```

Not sure if we need the thresholds there, and not sure if this would play nice with `@keyframes` that refer to phases.

> If the animation code needs to depend on knowing those relative sizes, or is easy to screw up when they invert on someone else's computer, we've designed a system that will fail depending on the environment a page is loaded in, and that's bad CSS language design.

The example shown doesn’t need to know the size of the subjects nor the scroller. It uses the sibling index of each element to limit when the animation runs, similar to how authors implement staggered animations.

> I also think the main idea of ViewTimeline is to animate along the phases we already define as intents to animate along phases of view (enter, exit, entire view, etc), and less so to fully animate across all possible parts of the scroll length. As in view's intent, and not view's length.

As shown in the example I linked to, this becomes a limitation when animating elements that are not the subject itself. In those cases you sometimes do want to target the “long-enter”/“long-exit”

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


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

Received on Wednesday, 7 December 2022 23:30:20 UTC