[scroll-animations-1] What's the point of animation-range?

[Loirooriol]

https://w3c.github.io/csswg-drafts/scroll-animations/#named-range-animation-declaration

The animation-delay and animation-range properties are both shorthands that set animation-delay-start and animation-delay-end together in a single declaration.

What's the point of having 2 shorthands if both have the same grammar and expand to the same set of longhands in the same way?

@cdoublev also confused in https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1252092947

@bramus said

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.

But then maybe restrict animation-delay to <time>{1,2}# and animation-range to [ <timeline-range-name> <percentage>? ]{1,2}# or something?

[ydaniv]

Note that the animation shorthand's second <time> value is parsed as animation-delay, so unless we add animation-range to the definition of animation we can't restrict animation-delay from accepting range values. Otherwise we can't declare a scroll animation with animation.

But at the same time, any animation-duration in a scrub animation (scroll or other) is meaningless. It's always 100%. Since I'm not an expert on values/parsing, would it make sense to have an alternative definition of animation that contains only ranges and no <time>? (@fantasai , @flackr)

[Loirooriol]

Once animation-delay becomes a shorthand, animation will need to expand into the longhands: animation-delay-start and animation-delay-end. So changing animation-delay doesn't have to affect animation, it depends on how it's defined.

And anyways, scroll-animations-1 doesn't seem to be changing animation, so its grammar is still as defined in https://drafts.csswg.org/css-animations-1/#propdef-animation, which uses <time>, regardless of the grammar of animation-delay. So if you want to define scroll animations in animation open a new issue I guess.

[ydaniv]

Once animation-delay becomes a shorthand, animation will need to expand into the longhands: animation-delay-start and animation-delay-end. So changing animation-delay doesn't have to affect animation, it depends on how it's defined. scroll-animations-1 doesn't seem to be changing animation, so its grammar is still as defined in https://drafts.csswg.org/css-animations-1/#propdef-animation, which uses ,

Of course, that's what I meant above. scroll-animations-1 depends on the definition of animation for defining an animation with a scroll-linked timeline, and it's using <time>, though, IIUC, the intent is to be able to set animation-delay in animation as ranges, for example:

animation: 1s linear contain fade-in my-view-timeline;

Currently animation doesn't contain animation-range in its definition, and that's why it depends on using delay, and is still required for delay to expand also to ranges.

Unless, my suggestion above, we can change the definition of animation and have an alternative definition, which only uses ranges, and not time, and thus will make your original suggestion valid, here:

But then maybe restrict animation-delay to {1,2}# and animation-range to [ ? ]{1,2}# or something?

And thus make them mutually exclusive.

open a new issue I guess

I'll do that 👍

[flackr]

I don't have a strong opinion on this. We use animation-delay (and animation-duration) because conceptually it represents the same concept (the offsets and lengths of the animation), just in the units of scroll and view timelines rather than document timelines. I feel like it's simpler to avoid adding new properties, and there are cases where allowed values could overlap. E.g. animation-delay: 50% could have meaning for both scroll linked and timed animations.

[fantasai]

What's the point of having 2 shorthands if both have the same grammar and expand to the same set of longhands in the same way?

This is an open discussion point, but I put both because reading animation-delay: range-name or even animation-delay: first-range x% second-range y% is really strange, it's not really a delay. But we can't get rid of animation-delay, so having it expand out as animation-delay-start and animation-delay-end seemed to make more sense than having animation-range expand out as animation-delay and animation-end-delay.

We could also flip things around and have animation-range expand to animation-range-start and animation-range-end with animation-delay being an alias of animation-range-start... or something else, open to ideas.

[flackr]

I put both because reading animation-delay: range-name or even animation-delay: first-range x% second-range y% is really strange, it's not really a delay.

Technically it is still a delay in the units of the timeline. I.e. in the same way that animation-delay: 1s delays a time-based animation until a certain time is reached, animation-delay: contain delays a view-timeline based animation until a certain scroll position is reached. I can see how there might be some confusion though.

The main issue I can think of with just using animation-delay is that when given a single <time> value it only sets the start delay (to preserve compatibility with animations today), however when used with a <range-name> it would set both start and end delays. We could make animation-delay: <range-name> invalid, and so animation-range: <range-name> is the way to implicitly set both delay-start and delay-end to a particular range but otherwise developers can use the two value animation-delay property or set animation-delay-start and animation-delay-end directly. This might be a bit awkward but avoids any redundant properties and explains why the 1-value range-name version sets both start and end.

[flackr]

So to summarize, think there's roughly 3 options to keep these properties cleanly separated:

Option 1: (hinted at by my previous comment)

1. animation-delay accepts <animation-delay-start> <animation-delay-end> but not <timeline-range-name>. As currently specified, if only start is specified end is treated as 0 (time delay) / 100%.
2. animation-range accepts only <timeline-range-name>, expanding it to animation-delay: <timeline-range-name> 0% <timeline-range-name> 100% Each property has a specific unique use case, and we maintain the backwards compatibility with the current animation-delay being only animation-delay-start. There would be no shorthand for animating from the start of one range to the end of another. We would continue to have the slight awkwardness where ranges don't feel like delays.

Option 2.a: (proposed above by @fantasai)

1. animation-delay is equivalent to animation-range-start for compatibility.
2. animation-range is roughly as specified except expanding to [<animation-range-start> <animation-range-end> | <timeline-range-name>]#. Specifying Animation-delay is effectively a legacy property name. As a new property we could have symmetry with both a time value or range name implicitly applying to both range-start and range-end. animation-range-end with a time value is somewhat confusing (if mapped directly to end delay) as it not the time at which the animation ends but the delay after the end of the effect to the end of the animation.

Option 2.b:

• Option 2, but treat animation-range-end as an absolute time value from the beginning. This doesn't map cleanly to endDelay in web-animations-1 and we would probably have to convert this to duration (if duration was auto) and the relative endDelay (if duration was non-auto) This would likely be closer to what developers would think of animation-range-end as meaning - i.e. the particular time or location at which the animation ends, but has additional conversion complexity and wouldn't map cleanly to the JS API - i.e. we may need more OptionalEffectTiming dictionary values to specify this.

In order I think I prefer 1, 2a, 2b, however there are good reasons for each.

[fantasai]

It might be too late at night for me to be thinking straight, but another proposal could be

Option 3:

• animation-delay (which expands to animation-delay-start and animation-delay-end) only takes absolute time values (as in Animations 1), and represent insets on the effective timeline range.
• animation-range (which expands to animation-range-start and animation-range-end) takes named range + offset values (as introduced in Scroll Animations), which represent absolute points on the timeline.
• In the future, if we have time-based animations that have named ranges, the properties interact by having delay values cut in from the start/end of the range.
• (I'm maybe too tired to think of an intelligent way for animation-range-end to interact with animation-duration......)

[flackr]

It might be too late at night for me to be thinking straight, but another proposal could be

Agreed, this is a reasonable third option, and I like that it handles the combination of range and delay in a way that makes sense (in the cases where range and delay make sense).

• (I'm maybe too tired to think of an intelligent way for animation-range-end to interact with animation-duration......)

IMO the existence of both duration and end are similar to the existence of both right and width on an absolute position box size. We should choose one to win if both are specified. If we follow the box sizing analogy, duration should win if specified.

[ydaniv]

The proposal in this comment: https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1306103577 is also relevant

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] What's the point of animation-range?, and agreed to the following:

• RESOLVED: Animation range and animation delay are separate things that compound

The full IRC log of that discussion

<Rossen_> https://github.com/w3c/csswg-drafts/issues/7901#issuecomment-1325538928
<dael> fantasai: When we were trying to figure out how to attach an animation to different ranges, named ranges in the timeline. Entry phase, exit phase, and the like and want to attach to some
<dael> fantasai: We allowed keyframes to take a named range as well a % to reprsent progress intot he range to be able to built animation that crosses ranges.
<dael> fantasai: Also wanted to take existing keyframes and attach to a range
<dael> fantasai: Did that with animation delay as a way of indicating where we wanted to attach it. Could give a named range and % into the range as delay
<dael> fantasai: That has weird ergonomix for author. Want to attach to entry phase and set animation delay to entry. Reason why we have animation range property is to make it feel less odd
<dael> fantasai: Becomes a question if we think about interaction what makes the most sense. flackr comment has several ways to make them intersect or have different responsibilities
<dael> flackr: I can present 1 & 2. Option 1 is keeping things close to today. Animation delay only spec start delay. Prop is turnt hat into a shorthand for start and end delay. preserve single value for compat
<dael> flackr: It was accept timeline range in each. animation range is for the case you want to cover a complete range. animation-range: enter sets it to enter 100%
<bramus> s/sets it to enter 100%/sets it to enter 0% enter 100%
<birtles> q+
<dael> flackr: Option 2 is closer to preserve existing delay as is and introduce animation range where you can spec a range, range start, range end and it maps to internal values. Effectively makes animation-delay somewhat of a legacy property b/c only specs start and range is everything delay does
<Rossen_> q?
<dael> fantasai: Third option is animation delay and animation range take effect at same time. Range set the range and delay is an inset into that itme
<dael> fantasai: animation-range:entry and animation-delay:value I start that value into the range.
<dael> fantasai: I think that has an advantage that it keeps delay simple and reasonable interaction between delay and range.
<dael> fantasai: I think those are the proposals on the issue
<dael> fantasai: My preference is 3rd
<dael> flackr: I prefer 3rd as well
<dael> birtles: I think we should think about why introduced group effects. Animation delay is relative to parent effect where if you have a sequence and delay b it'll offset start relative to a. Then what would an absolute delay mean? Or a range? We should think about that
<dael> birtles: Maybe we would decide they should be separate and delay is effect and range is animation as a whole
<bramus> q+
<Rossen_> ack b
<Rossen_> ack b
<dael> bramus: To make sure I understad, prop is to set an animation range to entry and then set an animation delay to 25% 75%. Is that correct?
<dael> birtles: That sounds like what it would be. Animation range applies first and puts on timeline
<Rossen_> ack fantasai
<dael> flackr: Slight correction. you probably didn't mean 75% end delay. Animation-delay:end is same meaning where it's amount of time after effect. 25% 25% would do wha tyou expect
<bramus> Got it
<dael> fantasai: Suppose in future have named, time based ranges. And you say you want to animation this during window. Express the delay in ms and you can do start and end and ms cut into it. If we add length-based you could also cut in with a length
<dael> fantasai: I think we still want to allow range to be entry 10% or whatever so you would add up %. If doing time + % it points to the point you've described. You add additional padding with the delay
<dael> Rossen_: I'm trying to make sense of the silence. Looks like "okay" silence
<dael> flackr: I think option 3 sounds good and might be better for previous issue
<dael> Rossen_: Prop?
<dael> fantasai: Animation range and animation delay are separate things that compound
<dael> Rossen_: Additional opinions or objections?
<dael> RESOLVED: Animation range and animation delay are separate things that compound

[flackr]

I see several referenced commits but when I click through to them github says they don't belong to any branch. However, when I look at the spec it looks like maybe they landed. @fantasai is there more needed to close this?

[fantasai]

Changes landed in https://github.com/w3c/csswg-drafts/commit/e6ca22a05f0450627ed81e2803ed66e45ca7ea83 (which you reviewed in https://github.com/w3c/csswg-drafts/pull/8219). For whatever reason GitHub seems to have decided lately that issue numbers in commit message titles don't count or something...

Anyway, I'll close this issue. Please file follow-up issues if anything needs follow-up. :)