[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 #7044 (comment)

@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: #7575 (comment) is also relevant