[scroll-animations-1] Phases for taller than scrollport subjects

[bramus]

Our current approach to the phases

I’ve been working on some visualizations for scroll-animations, to visually show how they are measured. For example, for smaller-than-scrollport-subjects:

For taller-than-scrollport-subjects, simply making the boxes bigger does not work, because that would mean contain 100% comes before contain 0%, which is impossible:

To solve this, we flipped the edge against which the subject is measured (note how the darker line on the center two subjects has flipped sides):

With that, we also shortened the range for enter/exit phases, in order to be able to use 1 set of keyframes that has no overlap between the enter-contain-exit phases:

Limitations of the current approach

This comes with two nasty side-effects imo:

1. The entry/exit phases are shortened, because phase change detection 
does not happen on the same edge

2. The meaning of enter and exit changes. This can be troublesome for an element that is initially smaller than the scrollport but becomes taller due to a resize.

This problem becomes clear in a demo such as https://codepen.io/bramus/pen/XWEeGZm no longer possible, where it’s not possible to create it using the new phases.

(FYI: the demo uses a version of the polyfill that measures things differently to make it work after all)

An alternative solution

To solve this, I would like us:

1. To not change the meaning of enter/exit, and have their measurements be done consistently
2. Introduce extra phases to allow the current interpretation of enter/exit for taller-than-scrollport-subjects.

Additionally, I also think we have our names wrong, as the current enter 100% for taller-than-scrollport-subjects visually means “it is entirely covering the scrollport”. This does not rhyme well the existing cover.

What I would like to propose, are the following phases. I have added the edge/threshold indicators from earlier versions of the spec as that might make thing easier to understand (this visualization tool of edges and thresholds might come in handy):

• Smaller than scrollport subjects
  • enter = end 0 → end 1
  • exit = start 1 → start 0
  • contain = end 1 → start 1
  • intersect = end 0 → start 0
• Taller than scrollport subjects
  • enter = end 0 → end 1
  • enter-cover = end 0 → start “1”
  • exit = start 1 → start 0
  • cover-exit = end ”1’ → start 0
  • cover = start 1 → end 1
  • intersect = end 0 → start 0

These visuals summarize the proposed changes:

The real ask

Maybe we can do a breakout session on this? Some time in the 2nd half of November maybe? Just before/after a WG meeting?

As you might have noticed by now, I have prepared slides for this :)

/ping All attendees of a previous breakout session: @fantasai @tabatkins @flackr @kevers-google @mirisuzanne @ydaniv @jensimmons @smfr @argyleink

[fantasai]

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.

Are there use cases for other phase interpretations? Yes. Should we find ways to enable them? Probably. But what we need to make really easy is the basic case: an animation where a semi-transparent element fades to opaque as it's brought in view and fades out as it leaves, or anything else on an equivalent timeline. And that needs to work reliably without the author knowing its size relative to the viewport or needing to think too hard about it.

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.

[ydaniv]

My main reasoning is that current design maps very cleanly with >90% of intents that I know, and pretty easily. I think the spec is pretty easy to understand, and also for authors to work with.
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.

[bramus]

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:

@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”

[fantasai]

I think defining a custom phase mechanism is overly complicated for something like "I want an animation phase that covers the time when the box is crossing the viewport edge". :) Why not just add two new animation phases: entry-crossing and exit-crossing?

[bramus]

SGTM! 👍

[fantasai]

Proposed Resolution: Add entry-crossing and exit-crossing timeline ranges for while an element is crossing the corresponding viewport threshold.

[bramus]

I took a jab at defining these new ranges in bramus@392a4de

[flackr]

SGTM2

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] Phases for taller than scrollport subjects, and agreed to the following:

• RESOLVED: add `entry-crossing` and `exit-crossing` to handle things which could be taller than the scrollport
• RESOLVED: keep entry as entry

The full IRC log of that discussion

<argyle> astearns: next issue, taller than scrollport stuff.
<argyle> bramus: essence of this issue boils down to the largest part of the issue, you cant do animations while they scroll into view or not when using the exisrting phases. this onlyu applies to taller than viewport subjects.
<bramus> https://github.com//issues/7973#issuecomment-1349970567
<argyle> bramus: fantasai suggests keep current phases but specify two extra phases, linked int his comment
<argyle> bramus: entry-crossing and exit-crossing, looks at subject itself while it's crossing that edge
<argyle> bramus: i dont have a visualization for it unfortunately. there's a spec adjustment that describes it
<astearns> https://github.com/bramus/csswg-drafts/commit/392a4deefdc546591ab48ed899aded52bd698467
<argyle> bramus: entry crossing would be subject taller than viewport, or any sized item, crosses the bottom
<argyle> bramus: until it's end edge coincides with the end edge of the scroller
<argyle> bramus: exit crossing is when the start edge of the subject coincides with the start edge of the scroller, until it moves entirely out of the scroller
<argyle> flackr: it's basically the other possible option when we decided the way we did to avoid the overlap of phases for trivial cases
<argyle> astearns: we expect people will still use entry and exit for most cases, but these new ones are for cases where it can be taller
<fantasai> illustration -> https://user-images.githubusercontent.com/213073/198659234-76702d8b-9770-43a0-9ee9-d81723e8c15b.png
<argyle> bramus: yes, this was a missing thing int he spec, and with this authors can do oanything they want
<ydaniv> SGTM
<argyle> astearns: any comments or concerns about adding more keywords?
<flackr> SGTM
<argyle> sgtm
<fantasai> +1
<argyle> RESOLVED: add `entry-crossing` and `exit-crossing` to handle things which could be taller than the scrollport
<astearns> ack fantasai
<Zakim> fantasai, you wanted to discuss follow-up question
<argyle> fantasai: we had discussed having the name of ranges be enter an exit or entry and exit. given we have entry-crossing, we should go with entry and exit.
<argyle> astearns: they should match
<argyle> fantasai: this new keyword tips things in the direction of entry being more appropriate
<argyle> flackr: i was going to say i dont love the names, but i dont have alternatives
<fantasai> note the current draft uses 'entry'
<fantasai> there's a issue asking if it should be 'enter'
<argyle> flackr: another way to think of this, is whether the element intersects the entry/exit edges of the scroller. but i dont think that helps us get a better name
<argyle> flackr: i'm fine to change to entry if that makes more sense
<argyle> fantasai: is it entry, i just want to close that issue
<bramus> q+
<argyle> astearns: resolve on keeping entry as entry
<astearns> ack bramus
<argyle> bramus: i found enter to match better, but english isnt my primary language. no scroll feelings
<bramus> q-
<argyle> astearns: enter is easier to spell to non english speakers
<argyle> fantasai: enter is a noun
<fantasai> s/enter/entry/
<argyle> astearns: my suggestion is we resolve now on keeping entry for consistency, but like everythihng, if peoeple come up with better ideas we can go ovoer this again in the future
<argyle> astearns: anyone have concerns with that direction? any objections to keep entry as entry?
<argyle> RESOLVED: keep entry as entry
<argyle> astearns: anything else?