[web-animations-2][css-animations-2] How should unspecified trigger range boundaries be resolved?

[DavMila]

In the web animations spec, animation-trigger-range-start, animation-trigger-range-end, animation-trigger-exit-range-start and animation-trigger-exit-range-end specify the boundaries of the ranges in which an AnimationTrigger will play, pause, reverse, etc. an associated animation. Valid values for these properties are similar to animation-range, e.g. “contain 10%”, “cover 100%”, etc.
How should these properties be resolved when not specified?

Some options we can consider are:

1. Using the boundaries of the named range (which defaults to “cover” for view timelines). E.g. “contain 10%” resolves to “contain 10% contain 100%”. This is what’s done for animation-range.

2. Using the boundaries of the scroll range (instead of the view timeline range). E.g. “contain 10%” resolves to “contain 10% scroll 100%”

Option 2 is useful for scenarios in which an author essentially wants a single point beyond which scrolling would trigger an animation. The author could just write, e.g., “contain 0%”. OTOH if they want to match the “contain” boundary then they have to set “contain 0% contain 100%".

With option 1, the tradeoff is the converse: they can simply specify “contain 0%” to mean “contain 0% contain 100%” and if they mean to refer to the entire scroll range then they have to use the scroll keyword, e.g. “contain 0% scroll 100%”.

I suggest going with option 1 which aligns with animation-range so developers don’t have to remember that the named ranges keywords expand one way for animation-range and a different way for animation-trigger-*range.

[ydaniv]

I think option 1 is what authors would more likely expect when using view timelines. Also, like you said, it's nice if we can have a consistent resolving for ranges across different properties.

Also notice that exit range properties allow an auto value as default which falls back to the corresponding value of the default range, and not to normal.

I suppose if you set only contain 10% for animation-trigger-exit-range-start it will resolve the end similar to option 1 above.

[DavMila]

Also notice that exit range properties allow an auto value as default which falls back to the corresponding value of the default range, and not to normal.

Ah yes, perhaps another issue worth resolving on: I agree that it would be nice to have a default value for the exit range boundaries that says "match the default range" but I know there's been some concern (example) in the past about specifying auto in a way that doesn't mean "user agent should do what makes sense". This doesn't mean that user agents can't treat auto this way, but maybe is a reason to instead consider using normal to mean "match the default range."

This would mean normal for animation-trigger-exit-range is different from normal for animation-range but I think this wouldn't be too problematic a difference for developers and may even be the more meaningful option if we establish some relationship between the default and exit ranges like 11910 discusses.

It would also mean that an author that means to specify "cover" range (which "normal" would have meant) as the exit range but not as the default range in the shorthand (animation-trigger) would need to specify the first 2 longhands, animation-trigger-range-start and animation-trigger-range-end, and "cover", i.e. they couldn't write animation-trigger: contain 0% or animation-trigger: contain 0% contain 100%. They would have to write animation-trigger: contain 0% contain 100% cover... but this would be the same with auto if the exit-range properties default to auto.

[ydaniv]

Ah yes, perhaps another issue worth resolving on: I agree that it would be nice to have a default value for the exit range boundaries that says "match the default range" but I know there's been some concern (w3ctag/design-reviews#1011 (comment)) in the past about specifying auto in a way that doesn't mean "user agent should do what makes sense". This doesn't mean that user agents can't treat auto this way, but maybe is a reason to instead consider using normal to mean "match the default range."

That is why I added the auto value, since normal is already specified to have a specific meaning and I did not want to overload that meaning depending on the context. So instead I figured that auto in this context means exactly that: "the UA should do what makes sense, which is match the corresponding value from the default range".

You think it's less appropriate here?

This would mean normal for animation-trigger-exit-range is different from normal for animation-range but I think this wouldn't be too problematic a difference for developers and may even be the more meaningful option if we establish some relationship between the default and exit ranges

In this case I'd prefer not having to parse normal based on the context. OTOH, I think auto is a value that can be parsed differently based on context, so would prefer that value to do a lookup on another property's value. But I'm open to hear otherwise.

It would also mean that an author that means to specify "cover" range (which "normal" would have meant) as the exit range but not as the default range in the shorthand (animation-trigger) would need to specify the first 2 longhands, animation-trigger-range-start and animation-trigger-range-end, and "cover", i.e. they couldn't write animation-trigger-range: contain 0% or animation-trigger-range: contain 0% contain 100%. They would have to write animation-trigger-range: contain 0% contain 100% cover... but this would be the same with auto if the exit-range properties default to auto.

That is a separate issue I briefly raised here.
I think I'll open a separate issue for that.

[ydaniv]

@DavMila please see #11948

[bramus]

While re-reading the thread that sparked scroll-triggered animations, I noticed this question was also covered in that thread.

See #8942 (comment) and the next few comments.

My first interpretation was that animation-trigger: view() alternate entry 100%; would resolve to animation-trigger: view() alternate entry 100% contain 100%;.

But then @flackr clarified that my interpretation was incorrect and that we should expand to “infinite” behavior instead of contain 100%.

So using scroll 100% here comes closest to this. As this is for the default trigger range, I would assume an omitted -end value for the exit trigger range would be scroll 0%

[ydaniv]

That is only if you specifically want the single triggering behavior, like the comment says:

If we want to support a single trigger point that is active for any position after it we need to have different behavior from the default animation range single value.

In that case you need that infinite behavior. So if you want a repeating/alternating triggering with a single point you need to specify something like: entry 100% scroll 100%.

But omitting a range boundary is not the same as trying to specify a single boundary.
Currently the spec says that default ranges are resolved similar animation-range, and omitted exit range boundaries default to their corresponding default range boundaries - being auto.

[DavMila]

But omitting a range boundary is not the same as trying to specify a single boundary.

I guess this comes down to something like bikeshedding because both approaches (expanding similar to animation-range or expanding to scroll 100%) give authors the same capabilities. I'm nudged towards having the default range expand to scroll 100% because that lets an author who wants to specify a single point specify a single value :)

[ydaniv]

I guess this comes down to something like bikeshedding because both approaches (expanding similar to animation-range or expanding to scroll 100%) give authors the same capabilities. I'm nudged towards having the default range expand to scroll 100% because that lets an author who wants to specify a single point specify a single value :)

So what you're saying is not really bikeshedding, but rather resolve on a different default value for animation-trigger-range-end, right? Or otherwise have normal resolve to scroll 100% instead of cover 100%?

Well we should also take into account not specifying anything, keeping both start and end as normal would result as scroll 0% 100%, right? IMO having these as defaults kind of defeats the purpose, right?
Also, I'd prefer to keep it consistent with animation-range-end and normal resolving as well, being cover 100%.

[DavMila]

Thinking about this a bit more: since the capabilities are the same either way, making it necessary for an author to have to specify, for example, entry 100% scroll 100% for the single point case really doesn't seem so bad, especially since it means we can stay consistent with animation-range by defaulting to normal and also preserve the meaning of normal.

I think the alternate example in @flackr 's demo demonstrates a common pattern where the element slides in and out at the bottom and top of the viewport, corresponding (roughly) to the cover range. I think it makes sense for the default setting, where a view() timeline has been declared, to cater to this use case (all the author needs write is contain or cover). If we default to scroll 100% for the end of the default range, the author has to write contain 0% contain 100%, otherwise the slide out at the top of the viewport won't happen.

I guess one other option is to make the default range dependent on the type of trigger, e.g. once defaults to scroll 0% scroll 100%, alternate, repeat and state default to cover 0% cover 100%. In which case maybe an auto keyword for the default range might make sense. But this, or a similar scheme, seems a bit developer-unfriendly to me as they'd have to keep track of which type maps to which default range.

Also, for the exit range I think using auto as the default and having it mean "match the default range" sounds good. That way the meaning of normal is fully preserved.

[ydaniv]

Great, so IIUC this means close as no change for now?

[DavMila]

Great, so IIUC this means close as no change for now?

I thought this, along with other issues #11971, 11915, 11914, would be good to put on the WG's agenda so we can come to a formal resolution on the expected behavior. Maybe agenda+?

[DavMila]

Thought I'd post one detail that occurred to me about this:

animation-trigger-exit-range: auto normal should mean the same as animation-trigger-exit-range: auto auto which means "match the trigger range."

and

animation-trigger-exit-range: normal auto should mean the same as animation-trigger-exit-range: normal normal which refers to the cover range.

The first case represents a slight expansion of the meaning of normal so that normal is defined in the newly introduced context of auto.