[scroll-animations-1] Entry/Exit Transitions for View Timeline effects

[fantasai]

There's a strong use case for wanting to animate while an element enters or exits the view, see e.g. https://github.com/w3c/csswg-drafts/issues/4912

However View Timelines as currently defined don't have the ability to bookmark the start and end of the entry or exit phase and to attach a set of animation frames to just that phase.

We could change the ability of view-timeline-fit to match the entry or exit phase, rather than the full cover or contain phase; but this would mean that many common use cases become a patchwork of separate animations on separate timelines stitched together, which is awkward.

[bramus]

As copied over from https://github.com/w3c/csswg-drafts/issues/6674#issuecomment-930542414 (per request by @fantasai):

Note that these "element slides into view"-animations 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:

@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: Sayanimation-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:

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 😅)

[fantasai]

Notes from chatting with @bramus, @mirisuzanne, and @rachelnabors:

• Remove view-timeline-fit
• Split animation-timeline into animation-timeline-name and animation-timeline-phase, with animation-timeline shorthand

  animation-timeline-name: [ auto | none | <timeline-name> ]#
  animation-timeline-phase: [ active | <timeline-phase-name> ]#
  animation-timeline: [ <'animation-timeline-name'> <'animation-timeline-phase'> ]#

• Define TimelinePhase API

   interface TimelinePhase { 
     readonly DOMString name;
     readonly double startTime;
     readonly double endTime;
   }

• Give AnimationTimeline ability to say what TimelinePhases are in effect, e.g. by querying a Set of some kind.
• ViewTimeline defines the following phases:
  • entry from when the box first comes into view from until it either is completely within view or completely covering the viewport
  • exit same, but on the other side
  • contain, while the box is fully contained within or fully covering the viewport

Open Questions

• Are these called phases, or something else, given we have these phases already: https://www.w3.org/TR/web-animations-1/#the-timelinephase-enumeration
• How are entry and exit distinguished? Is it by writing mode of the scroll container, or are we tracking where the box originally came into view from somehow?

[ydaniv]

These phases look pretty good for some cases, but I have couple of quite common cases which don't seem to be very straightforward using those:

1. The "animate-while-sticky" case: was very prominent effect in the apple.com product LP's, where scrubbing the effect would start once the source becomes sticky (position), and end once it's started being pushed up again. See example: https://codepen.io/ydaniv/pen/OJOobVR. Perhaps we could achieve this with a cover phase? Or perhaps introducing margins?
2. The "background scroll effect" case: quite common on Wix sites, where the source is a container, and the target is usually a media element clipped by the source. These events usually start in some threshold in entry and end at another on contain or even at exit. So question is how do we stretch an effect across phases?

[flackr]

• Define TimelinePhase API

  interface TimelinePhase { 
    readonly DOMString name;
    readonly double startTime;
    readonly double endTime;
  }

How does a developer get access to this TimelinePhase instance? In the CSS API the phase is named, wouldn't they name the phase in the JS api as well? E.g. the same as naming fill: 'both' | 'forwards' | 'backwards' | 'none'?

Minor nit: These times should be CSSNumberish to match the units used by the timeline based on how we resolve issue #7045, whether that's pixels or percentages.

ViewTimeline defines the following phases:

Do we need a phase such as cover which would be from entry to exit or would this be the active phase?

Open Questions

• Are these called phases, or something else, given we have these phases already: https://www.w3.org/TR/web-animations-1/#the-timelinephase-enumeration

We may be able to remove the existing timeline phase (Timeline phase was added to be able to disambiguate time 0 when the scroller actually reaches the 0 position from before reaching that position - which could be more easily handled by allowing times outside of the timeline's "active" range, see #4325) , or simply augment the timeline phase with these new phases.

• How are entry and exit distinguished? Is it by writing mode of the scroll container, or are we tracking where the box originally came into view from somehow?

My vote would be for writing mode of the container. I don't think we should have hysteresis based on scroll direction.

[birtles]

Jumping on the bikeshedding part here: I'd vote for not using the term "phase" here when describing the relationship of the animation to element positioning/containment. Phases are already used in a few places like effect phases and the timeline phases mentioned above. In both cases they have values "before", "active", "after" (and "inactive") and are a read-only value describing something about the progress of the animation.

This feels like quite a different use of the term such that overloading it would cause confusion.

[flackr]

I should add I don't think this solves the original use case as simply as offsets did. e.g. with offsets you can apply an entry and exit effect with a single animation:

const timeline = new ScrollTimeline({
  scrollOffsets: [
     { target: image, edge: 'start', threshold: 0 },
     { target: image, edge: 'start', threshold: 100 },
     { target: image, edge: 'end', threshold: 100 }, 
     { target: image, edge: 'end', threshold: 0 }
  ]
});

const effect = new KeyframeEffect(
  image,
  { opacity: [0, 1, 1, 0]},
  { duration: 1000, fill: both }
);

const revealUnrevealAnimation = new Animation(effect, timeline);
revealUnrevealAnimation.play();

However, defined as phases this has the exact issue that was of concern in #4912, that the entry and exit need to be separate animations. That said, I think it's workable to define these separately as I find it a little awkward that if you don't match the number of scroll offsets to the number of keyframes that the offsets are not keyframe aligned.

[flackr]

I think a simple solution is supporting entry/exit animations by adding start and end values (logical edges of the scroller) to view-timeline-fit and possibly renaming view-timeline-fit to something more appropriate given it's not quite the same as other fit properties, perhaps view-timeline-range? This could optionally be a two-value attribute to allow specifying a different point for the entry from the exit.

Could you explain more about how supporting specified phases on an animation works? If the object is larger than the scroll port, the phases can overlap. What time do you get from the animation when two phases are active? Does the exit phase automatically go from 100% to 0% progress to reverse the enter phase? I think the phases should always be a single start / end offset range - so we could support specifying a start and end phase / fit and that would set the 0% and 100% progress points respectively on that scrolling axis.

[kevers-google]

view-timeline-range: cover | contain | start | end | [ custom offset pair ]

sounds good. I share Brian's concern over potential confusion if we overload 'phase" with a different meaning from effect phase and timeline phase.

We can create some interesting effects with just a single start and end offset by using additional keyframes in the animation, animation delays, and timing functions.

If the ease of use gap is deemed too great between the keyword values for view-timeline-range and the custom offsets, we could add a bit more flexibility by introducing view-timeline-insets. This would allow you to use a named range as a starting point and tweak the start and end offsets (e.g. contain but with a 20px margin). This approach may be easier than computing custom offsets, keyframe boundaries or animation delays for some users.

[flackr]

I think the main challenge is that the current definition of cover and contain implicitly correlate start / end offset to opposite edges of the viewport. If we could specify which edge of the viewport we were referring to, enter and exit animations are equivalent to the ranges [end 0%, end 100%] and [start 100%, start 0%] (note end is first because the item first comes in to the "end" side of the viewport). What if we allowed specifying both offsets in terms of the start and end edges of the viewport, e.g.

view-timeline-range: [start|end]? <percentage> [start|end]? <percentage>?

If you omit either [start|end] value it would imply the end edge followed by the start edge. If you omit <percentage> we use the same value.

In this syntax, cover would map to end 0% start 0%, contain would map to end 100% start 100%, enter would be equivalent to end 0% end 100% and exit would be equivalent to start 100% start 0%. If we assume the existing mapping of cover to 0% and contain to 100% then the existing view-timeline-fit values would work as expected.

Note that specifying the start edge followed by the end edge would almost always produce a backwards range. This is a pre-existing problem with contain when the object is larger than the viewport.

[bramus]

view-timeline-range: [start|end]? <percentage> [start|end]? <percentage>?

I like this, as it gives me – as an author – the freedom to use any combination without needing to speed up keyframes or anything like that! (Also see what I described earlier in "Braintwist on the braintwist")

This is a pre-existing problem with contain when the object is larger than the viewport.

Sometimes it also is an opportunity, as demonstrated in this demo: https://codepen.io/bramus/pen/QWGbOBQ

[kevers-google]

I also quite like:

view-timeline-range: [start|end]? <percentage> [start|end]? <percentage>?

This would even allow reversing the direction of the animation by reversing the edges.

progress = (position - start) / (end - start) * 100%

also works if start > end as both the numerator and denominator will be negative when the scroll position is between the end points, resulting in a progress that is bounded between 0 and 100%.

[flackr]

FYI the scroll timeline polyfill has an implementation of ViewTimeline with the four values, but not yet the additional proportions. You can see how these work on the demo page: https://flackr.github.io/scroll-timeline/demo/view-timeline/

[fantasai]

@birtles Wrt phases... I think it is an overlapping concept with timeline phases, it's just that we'd need timeline phases to be non-exclusive. You'd be in the active phase as well as one or more named phases specific to that timeline. Don't think it's particularly inconsistent to call those phases.

@flackr

wrt https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1059339349

How does a developer get access to this TimelinePhase instance?

As mentioned in https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1047134956 : “Give AnimationTimeline ability to say what TimelinePhases are in effect, e.g. by querying a Set of some kind.” ... we didn't hash out exactly what that API would look like. Seems from your comment that maybe we can repurpose .phase?

Do we need a phase such as cover which would be from entry to exit or would this be the active phase?

Coincides with active, but I suppose an alias would be possible since we'd already need to support overlapping phases.

My vote would be for writing mode of the container. I don't think we should have hysteresis based on scroll direction.

WFM.

@flackr @kevers-google

view-timeline-range: cover | contain | start | end | [ custom offset pair ] view-timeline-range: [start|end]? [start|end]? ?

I like this direction for replacing view-timeline-fit.

I'll note doesn't solve the problem mentioned earlier of binding entry and exit animations to the entry and exit phases in one animation, though. For an animation to do that, it needs to assign frames specifically to the start/end of the entry and exit phases. We could allow the creation of multiple view timelines on a single element and assign them separate animations, but I think it's more natural to have a single timeline and an ability to bind frames to named phases or bookmarks in that timeline. And to do this in a way that the common things to do (like entry + exit animations) don't need a lot of manual setting up.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] Entry/Exit Transitions for View Timeline effects.

The full IRC log of that discussion

<dael> Topic: [scroll-animations-1] Entry/Exit Transitions for View Timeline effects
<dael> github: https://github.com/w3c/csswg-drafts/issues/7044
<dael> flackr: With view timeline needed to support use case of entry and exit animations that original view timeline attribute didn't cover
<dael> flackr: A bunch of discussion in issue about adding phase concepts and various discussions
<dael> flackr: I prop simplified alternative to jsut express range of view timeline in terms of when starts and ends relative to element's visibility. That allows you to express from element's entry, exit, and previous cover and contain values. Can map cover and contain to longhands
<fantasai> https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1115297671
<fantasai> view-timeline-range: [start|end]? <percentage> [start|end]? <percentage>?
<dael> flackr: May 2nd comment has proposal
<dael> fantasai: I think suggested tweaks are a good idea. I like the direction. might not be enough. one think that's awk is if you want to def an animation that has a particular behavior during entry, different when visible, and third when exiting
<dael> fantasai: Fade in, pulse, and fade out. Can't do that unless allow binding multiple view timelines on a single element. Becomes ergonomically a problem. Would like to expose a single timeline with phases where can attach set of keyframes even if not sure length of it
<dael> fantasai: That would allow more logical ties of parts of animation together including possibly expanding to user defined things in the future. other types of timelines might have phases in the future
<dael> fantasai: I think it's going in a good direction, but more things to explore
<dael> flackr: Covering the first point, I think that spec a list of view timeline ranges wouldn't be that ergonomically awk. Reason I'm concerned with setting multiple phases is that those phases can be overlapping. Can have element that's large enough that it nters at same time as exits. That gets complicated to spec what should happen
<dael> fantasai: Yeah. That's something we need to think about. Had a definition where once element fill screen it's considered to be no longer in entry phase and now is in contain phase until starts to exit
<dael> fantasai: That said, you could define phases in a way that they overlap and if attaching keyframes how does that work
<dael> fantasai: I think they are questions we should expolre. Proposal earlier attaches to different animations and would cascade as animations. I think weird if a large number of people will want separate phases for entry and exit and each person needing 3 timelines and reference them is a lot of unnecessary work. We should create those timelines.
<miriam> +1 fantasai
<dael> fantasai: If we decide sep timelines is right we should create 3 timelines that are named this way.
<dael> flackr: Create a shorthand to make it easy to attach a timeline to a range
<dael> fantasai: Alternative is concept of phases in timeline which is same as mutli timeline but it's the same as having a single timeline and attach phases to that timeline. Conceptually you still have 1 timeline which make sense since it's this one element moving through screen
<dael> flackr: Also examples of an animation that runs on enter and exit phase. Unclear on what that's supposed to do. Same animation start to finish on enter and exit?
<dael> fantasai: If that's how you spec, yeah? If want way to reverse animations easily could make that sntax
<dael> flackr: I think they should be separate animations.Otherwise it adds complexity
<dael> fantasai: if we add timelines for other things we're likely to way to have concept of phases or have ability for author to create custom phases and assign frames to names sections. Might be useful in future for other types. I don't think will stay as this one complex thing that's only for view timelines. Haven't thought a lot about which but seems useful
<dael> flackr: I can see the appeal to that. Probably limited subset to that feature that is just spec phase an animation runs during
<dael> flackr: A bit worried about overlapping phase and could be confusing when enter means something different depending on sie of scroller. Need more experimentation
<dael> fantasai: Yeah. And more thinking. I don't think ready to resolve. Maybe a separate call to explore and brainstorm instead of just try and resolve
<dael> fantasai: Prop: Arrange a side call for anyone interested in view timeline entry/exit to brainstorm and get ideas to aim for something more concrete
<dael> fantasai: If people are interested I can try and set something up
<ydaniv> +1
<dael> Rossen_: Okay
<dael> Rossen_: Is there anything else we want to do here and now?
<dael> fantasai: Don't think so
<dael> flackr: Pushing until call is fine. I added to agenda b/c not a lot of commenting on the issue
<dael> Rossen_: Let's do that

[flackr]

I think naming phases (specific term to be bikeshedded) from the timeline to use should work fine as long as they're not disjoint. However, given that setting a phase is equivalent to implying the startTime (which currently I think can only be explicitly set from the web animations API) and duration, we could consider exposing this explicitly as setting the start time and end time of an animation in reference to phases on its timeline. E.g.

animation-start-time: <timeline-phase-name> <percent>
animation-end-time: <timeline-phase-name> <percent>

Longer term we could even accept these as keyframe offsets similar to how from and to map to 0% and 100% we could map <timeline-phase-name> <percent> to the appropriate offset of that point within the animation's overall duration.

e.g.

@keyframes slide-in-out {
  from { transform: translateY(100%); }
  contain 0% { transform: none; }
  contain 100% { transform: none; }
  to { transform: translateY(-100%); }
}

Of course open to bikeshedding the exact syntax.

[kevers-google]

Expanding on Rob's idea:

In the web-animations-1 spec, timeline.currentTime is a scalar quantity and used in animation.currentTime calculations. It is possible that we could extend the notion of current time (in web-animations-2), adding a context-specific time, where the context would be the phase-name in the case of a view timeline. A monotonic timeline or a ScrollTimeline that is not a ViewTimeline would have a single global context. The value of timeline.currentTime would be based on the default/global context for the timeline; however, calculations to get/set the start/current time of an animation could be updated to use the context specific time, defaulting to the global context if the context has not been set.

This would allow multiple animations to use the same ViewTimeline instance with different ranges/phases.

[flackr]

@kevers-google I think we're saying different things. In my simplified proposal, currentTime would be the same, and what would change is at which times your animation starts. For example: ViewTimeline

• At time 0%, the element is out of view touching the bottom of the scroller, this is also the start of the enter phase.
• At time X% (X depends on layout), the element is fully in view at the bottom of the screen, this is the end of the enter phase and the start of the contain phase
• At time (100 - X)% the element is fully in view at the top of the scroller, this is the end of the contain phase and the start of the exit phase.
• At time 100% the element is just out of view above the scroller, this is the end of the exit phase.

Specifying contain 0% would be internally translated into X%

[kevers-google]

Gotcha. So an animation would run between X% and Y% where the percentages are calculated based on the named range?

We already have the start and end delays for an animation. Would it make sense to extend their use to cover use cases for a ViewTimeline? Alternatively, the start and end times could be used to set the delays.

[birtles]

@birtles Wrt phases... I think it is an overlapping concept with timeline phases, it's just that we'd need timeline phases to be non-exclusive. You'd be in the active phase as well as one or more named phases specific to that timeline. Don't think it's particularly inconsistent to call those phases.

I'm still not stoked about overloading the term "phase" here -- it seems like a different layering, at least if it's something mutable. It seems like "cue" or something like that would be better for the mutable property? For describing the current state of the world like in Rob's example (e.g. "start of the enter phase") that phase makes sense, however.

[bramus]

Longer term we could even accept these as keyframe offsets similar to how from and to map to 0% and 100% we could map <timeline-phase-name> <percent> to the appropriate offset of that point within the animation's overall duration.

e.g.

@keyframes slide-in-out {
  from { transform: translateY(100%); }
  contain 0% { transform: none; }
  contain 100% { transform: none; }
  to { transform: translateY(-100%); }
}

Of course open to bikeshedding the exact syntax.

Recently came up with something like this, which seems pretty similar:

@keyframes reveal-somethingelse-unreveal {

  enter {
    0% {
      opacity: 0;
    }
    100% {
      opacity: 1;
    }
  }

  contain {
    0% {
      …
    }
  }

  exit {
    to {
      opacity: 0;
    }
  }

  /* Regular keyframes, in case not linked to a view-timeline */
  from {
    opacity: 1;
  }
  to {
    opacity: 0;
  }
}

To my surprise this syntax doesn't seem to break current implementations, which is nice :)

[flackr]

@bramus In your example, the regular keyframe from and to would overwrite the enter 0% and exit to values. In this particular case they're the same so it wouldn't matter but just thought I'd point out that the presumption is that regular percentage keyframes would still be included.

Then in order to ensure it still doesn't break after we support these phase blocks I think phase keyframes which are not part of the attached timeline would be ignored.

[flackr]

@tabatkins @fantasai Do you have the notes from the meeting?

[bramus]

@flackr https://lists.w3.org/Archives/Public/www-style/2022Jun/0013.html

[ydaniv]

💭 throwing another naming idea for phase: view-phase 💭

[fantasai]

Summary of where I think we're at from the meeting notes:

• Remove the phase API from Web Animations 1, and remove the before/after concepts, keeping just active/inactive states.
• Add the concept of named timeline phases. Certain types of timelines (such as ViewTimelines) will provide such phases. (In the future, other types of timelines may offer named phases, or we might add the ability to have custom named phases.)
• Rename timeline inactive/active to states in the spec (not user-exposed) to avoid conflating with phases. Leave this all open for bikeshedding.
• ViewTimelines will provide entry/exit/contain as named phases.
• Add ability for a keyframe to name not just a percent, but a keyword and a percent, representing that percentage progress through that named phase of the timeline. @keyframes { ... exit 0% { ... } ... } See flackr's comment
• Add ability to specify start and end delays in terms of position in a named phase position (keyword + percentage), e.g. animation-delay: contain 0%; animation-duration: contain 100% attaches the animation between the 0% and 100% points in the contain phase. (See also issue 4342].)
• Add shorthand that expands a phase name to 0% start delay and 100% end delay. E.g. animation-phase: contain expands to animation-delay: contain 0%; animation-end-delay: contain 100%.
• Add an API to timelines to allow retrieving information about whether we're in a named phase and how far into it, in consideration that multiple named phases might be able to overlap. E.g. AnimationTimeline.getTime() which returns .currentTime by default, and returns time within the named phase if one is passed in.
• Interaction with stickypos might need more thought.

[bramus]

Extra notes (mainly for myself so that I don’t forget 😅):

• It should be easy to reuse existing keyframes as the keyframes for a phase: e.g. a fade-in from a generic library to be used as the keyframes for the enter phase
• It should be easy to map those keyframes to a part of a phase; e.g. apply that fade-in only between enter 50% 100% (was also included in list of comments above)

[css-meeting-bot]

The CSS Working Group just discussed entry/exit transitions for view timeline effects, and agreed to the following:

• RESOLVED: Accept all of fantasai's bullet points from her summary, except for the keyword+% in @keyframes

The full IRC log of that discussion

<TabAtkins> Topic: entry/exit transitions for view timeline effects
<fantasai> Summary at https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1175722383
<TabAtkins> TabAtkins: ah yeah i was at this breakout, i agree with the conclusions
<TabAtkins> [multiple people were in this breakout, including smfr from apple who's not at this meeting]
<TabAtkins> astearns: Anyone at the meeting who have any concerns about the line items?
<TabAtkins> astearns: my inclination is to take the bullets unless someone has a concern
<TabAtkins> ydaniv: regarding changing the @keyframes rule, adding the keyword+%
<flackr> qq+
<TabAtkins> ydaniv: imho, this would be a mistake becuase these are timing options
<bramus> Link: https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1144946715
<TabAtkins> ydaniv: what we have in keyframes are offsets
<TabAtkins> ydaniv: mixing these are wrong
<TabAtkins> ydaniv: would be later confusing, as we might have some of these in keyframes, and some define din the animation itself, and which would win?
<astearns> ack flackr
<Zakim> flackr, you wanted to react to flackr
<TabAtkins> flackr: the way these are resolved, they resolve to offsets
<TabAtkins> flackr: it's basically a calculation that becomes a normal keyframe offset, based on your timeline
<TabAtkins> astearns: so this is authoring convenience?
<TabAtkins> flackr: yes
<TabAtkins> ydaniv: but like, exit/contain/enter map to seconds in a normal timeline
<TabAtkins> ydaniv: so those look like timing options
<TabAtkins> flackr: It doesn't affect the times of those durations
<TabAtkins> flackr: it maps to the offset in your animation that is the timeline progress
<bramus> See visualization (from the breakout): https://excalidraw.com/#room=59388d327d8f3aa8ddb2,6FU4m3Fw4huQ-JGyP23o5A
<TabAtkins> flackr: if that's outside your animation's duration, that's fine, it's like specifying a keyframe of -50% or 150%
<TabAtkins> astearns: does that address you concern, yehonatan?
<bramus> q+
<TabAtkins> ydaniv: not really convinced, but if rob is sure this is okay
<TabAtkins> astearns: i see two ways forward for this line item. this one seems separable, so we could resolve to do everything but this, and open a separate issue for it; or we could resolve to do it all, and you raise an issue to question it.
<TabAtkins> flackr: confirm that it's separable
<TabAtkins> ydaniv: yeah let's open a separate issue and continue discussion there
<TabAtkins> ydaniv: if we could defer this issue it would be nice
<TabAtkins> astearns: okay, any discussion on the rest?
<TabAtkins> bramus: the syntax that rob came up with seems fairly reasonable and logical if you think of the phases
<TabAtkins> bramus: and their %s
<TabAtkins> bramus: It's very understandable for authors, I think it makes sense
<TabAtkins> bramus: i don't see why we shouldn't move this forward
<TabAtkins> bramus: there have been some back and forths on what to do, and this seems very reasonable
<TabAtkins> astearns: right, not moving this out with prejudice
<TabAtkins> astearns: just want to make sure we make progress on the rest first
<TabAtkins> ack bramus
<TabAtkins> astearns: any concerns with anything else?
<TabAtkins> astearns: bramus you had two extra notes, is that part?
<TabAtkins> bramus: No, they're part of the thing we just sliced off
<TabAtkins> astearns: So proposed resolution is to accept all the bullet points from fantasai's summary, except for the keyword+% in @keyframes; we'll separate that to another issue
<TabAtkins> fantasai: That is the core part of this issue
<TabAtkins> astearns: rob mentioned this is just author convenience
<TabAtkins> flackr: You can bind to a specific phase
<TabAtkins> flackr: this give syou the ability to more conveniently say, within a @keyframes, follow these phases
<TabAtkins> flackr: it does mean you can't do one single animation that's an entry/exit, you ahve to split it up
<TabAtkins> fantasai: right it's not awesome
<TabAtkins> fantasai: you frequently want to ahve one animation
<TabAtkins> fantasai: i'm totally okay with resolving on it all and then discussing it
<TabAtkins> fantasai: but i don't think leaving it out is closing the issue properly
<TabAtkins> bramus: I follow elika on this one
<TabAtkins> astearns: so proposed resolution is [repeated from last time]
<TabAtkins> astearns: continue the discussion on the omitted point in this issue
<TabAtkins> astearns: Objections?
<flackr> I agree this is a really valuable addition to the issue
<TabAtkins> RESOLVED: Accept all of fantasai's bullet points from her summary, except for the keyword+% in @keyframes

[css-meeting-bot]

The CSS Working Group just discussed breakout summary, and agreed to the following:

• RESOLVED: Adopt the previously-skipped bullet point from fantasai's summary

The full IRC log of that discussion

<TabAtkins> Topic: breakout summary
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7044
<TabAtkins> flackr: we established the keyframe offsets never change the animation timing, they're offsets as normal
<TabAtkins> flackr: same mechanism could also address the request from users to be able to set keyframes to particular times, like "500ms after the start of the animation"
<TabAtkins> flackr: i think we were all ok with this line of thinking
<TabAtkins> I'm okay with this
<TabAtkins> ydaniv: 100% correct
<TabAtkins> ydaniv: if this allow smore flexibility and sugaring, taht's great
<TabAtkins> ydaniv: if other libraries want to create reusable effects that's also possible
<TabAtkins> astearns: so proposed resolution is to adopt the skipped bullet point
<TabAtkins> RESOLVED: Adopt the previously-skipped bullet point from fantasai's summary
<TabAtkins> bramus: In a follow up comment, i said it should be easy for authros to reuse exisitng keyframes for a phase
<TabAtkins> bramus: like a generic animation library with a fade-in or fade-out, should be able to say "use this keyframes fro the entry phase"
<TabAtkins> ydaniv: sounds good for animation 2
<TabAtkins> fantasai: do we already have this?
<TabAtkins> flackr: yes, but for separate keyframe rules
<TabAtkins> bramus: so i'd like to be able to say...
<bramus> https://www.irccloud.com/pastebin/vPjQFIza/
<bramus> @keyframes bla {
<bramus> enter fade-in;
<bramus> exit fade-out;
<bramus> }
<TabAtkins> bramus: and maybe the ability to say `enter 50% fade-in`, etc
<TabAtkins> fantasai: so the ability to say start, end, and the name of a @keyframes
<TabAtkins> fantasai: similar to syntax we ahve for the animation-phase shorthands
<TabAtkins> fantasai: i think that makes a lot of sense, but also is def a separate issue
<flackr> +1
<TabAtkins> fantasai: happy to resolve if we want to do this, but should probably open a separate issue to flesh it out
<TabAtkins> astearns: i heard an opinion that this should be next level
<TabAtkins> fantasai: yeah and this def isn't a scroll-animations issue, it's a general animations issue
<TabAtkins> miriam: this is basically being able to compose scenes out of an animation
<TabAtkins> ydaniv: in animation-2 we have group/sequence, doesn't this map to that?
<TabAtkins> flackr: those can overlap so compositing is a complex topic
<TabAtkins> TabAtkins: but yeah this is related
<TabAtkins> fantasai: so yeah great idea, should be generic to all animations
<TabAtkins> astearns: given this is a new idea, i'd like to see a new issue with the proposed syntax, give people a chance to look at it before resoling
<TabAtkins> bramus: i'll open a new issue
<TabAtkins> astearns: in the animations-2 tag
<flackr> css-animations-2 i think this would be?
<TabAtkins> yes

[flackr]

• Remove the phase API from Web Animations 1, and remove the before/after concepts, keeping just active/inactive states.

FYI, removing the phase API and before/after from web-animations-1 was already resolved in #7240

• Add shorthand that expands a phase name to 0% start delay and 100% end delay. E.g. animation-phase: contain expands to animation-delay: contain 0%; animation-end-delay: contain 100%.

@birtles I wanted to get your take on the phase naming here. I agree that the term phase is overloading a concept that we already have in animations (even if it's currently not really a factor in timelines with them being either active or inactive) with something that isn't the same.

How about a vote on possible alternatives with emoji reactions? Feel free to comment and suggest alternatives: 👍 animation-phase: enter; 😄 animation-range: enter; 🎉 animation-time-range: enter; ❤ animation-cue: enter;

[birtles]

@birtles I wanted to get your take on the phase naming here. I agree that the term phase is overloading a concept that we already have in animations (even if it's currently not really a factor in timelines with them being either active or inactive) with something that isn't the same.

How about a vote on possible alternatives with emoji reactions? Feel free to comment and suggest alternatives: 👍 animation-phase: enter; 😄 animation-range: enter; 🎉 animation-time-range: enter;

Thanks! One other thought, does animation-cue make sense?

[ydaniv]

I think cue makes less sense here since it reflects a signal/instant, not a period of time/pixels.

[cdoublev]

Regarding the latest changes from https://github.com/w3c/csswg-drafts/commit/2152a232f0b050e2aa148d95f32a0fff61cf259b, can you please provide me some clarifications on the grammar of <timeline-range-name>? Can it be defined with a basic syntax like <custom-ident> (to allow authors to declare their own custom named timeline ranges in a future API), or with | separated timeline range names, currently restricted to the view progress named timeline ranges: cover | contain | entry | exit?

Also, both animation-range and animation-delay are shorthands for animation-delay-start and animation-delay-end? What is the purpose of animation-range? Which shorthand should serialize (assuming both sub-properties have a declaration)?

[bramus]

Regarding the latest changes from 2152a23, can you please provide me some clarifications on the grammar of <timeline-range-name>? Can it be defined with a basic syntax like <custom-ident> (to allow authors to declare their own custom named timeline ranges in a future API), or with | separated timeline range names, currently restricted to the view progress named timeline ranges: cover | contain | entry | exit?

Right now only those 4 – cover | contain | entry | exit – are defined/allowed. There currently is no intention to allow authors to define their own view timeline ranges – at least not at this point.

I think the rather loose syntax is there because that particular section will move to the css-animations-2/web-animations-2 spec over time. This leaves it open for other specs – other than scroll-animations-1 – to also define extra possible values, without requiring an update to the (future) css-animations-2/web-animations-2 specs.

Also, both animation-range and animation-delay are shorthands for animation-delay-start and animation-delay-end? What is the purpose of animation-range? Which shorthand should serialize (assuming both sub-properties have a declaration)?

Same question. Found it weird to have two properties target the same> Otoh I do understand the need for animation-range: it is more readable in the content of scroll-linked animations. E.g.animation-range: exit is easier to grasp than animation-delay: exit.

[flackr]

I think this is done. As far as I can tell @fantasai you have edited in the resolutions here, right?

[fantasai]

Yeah, looks like I forgot to close the issue.