[web-animations] How/when do the "rangeStart/rangeEnd" attributes the Animation interface get evaluated

[weinig]

How/when do the <length-percentage> values that can be passed to the rangeStart/rangeEnd attributes on the Animation interface (or via KeyframeAnimationOption) when assigning a DOMString, get resolved.

Specifically, the KeyframeAnimationOption section for rangeEnd says "A DOMString value is parsed as an animation-range-end value to yield a TimelineRangeOffset". animation-range-end is defined as [ normal | <length-percentage> | <timeline-range-name> <length-percentage>? ]#, so, <length-percentage> values will have to resolved.

Given all that, how/when should a string like 1em be resolved?

[ydaniv]

I suppose you have to have an active timeline in order to resolve percentages.
So I assume whenever both of the following two apply:

1. The property range* is set.
2. The Animation.timeline becomes active

Meaning, when a timeline becomes active, any set range* property is resolved.
Or, when a range* property is set, if the timeline of the associated animation is active, that property is resolved.

[weinig]

This is not meant to be an issue about percentages, which seem to be well defined to happen at use time like animation-range-start/animation-range-end, but rather about things that get resolved normally for computed style, like font relative units (the em example) or sibling-index().

[ydaniv]

OK, but as I understood it you're specifically asking about the imperative interface, right? So can there be a different time to resolve these, other then what I suggested?

[weinig]

I don’t understand exactly what you are proposing/stating?

Are you saying the spec already defines this clearly and I just missed it? If so, can you point me to the spec text that states it?

Or are you proposing how it should be specified? If so, it seems to be missing important details. Going back to my example, how are the font relative units resolved?

The only other place I can think of that tries to use parsed CSS property values outside of normal CSS usage is DOMMatrix (https://drafts.csswg.org/geometry/#dommatrix-parse) which clarifies that only absolute lengths are supported.

I think at least that level of detail is needed here.

[ydaniv]

Are you saying the spec already defines this clearly and I just missed it? If so, can you point me to the spec text that states it?

Or are you proposing how it should be specified? If so, it seems to be missing important details. Going back to my example, how are the font relative units resolved?

Since you opened the issue I'm assuming something is probably missing. I'm simply trying to understand what are the options for the resolution time. But I see now we're also concerned with "how" the resolution works.

Well, the range* properties belong to an animation, which has an associated effect, and effect has a target Element. It's not abstract like a DOMMatrix. Shouldn't that solve the "how"?

[weinig]

Well, the range* properties belong to an animation, which has an associated effect, and effect has a target Element. It's not abstract like a DOMMatrix. Shouldn't that solve the "how"?

I don't think an instance of Animation always has an effect, (the effect is optional in the constructor) and similarly, an effect doesn't always have a target element (the constructor for KeyframeEffect allows passing in a null target).

It's plausible that rangeStart and rangeEnd are never utilized if there is no effect and/or target, but that is not totally clear to me.

But even if we assume that effect's target is available at times where resolving rangeStart and rangeEnd happens, it's not clear how that should work.

I think new hooks are needed in one of the base CSS specs (CSS Syntax or CSS Cascade maybe) to specify what it means to parse and resolve a CSS property outside the normal cascade.

[ydaniv]

But even if we assume that effect's target is available at times where resolving rangeStart and rangeEnd happens, it's not clear how that should work.

Sorry, I may be out of my element here (none intended), can you explain why when you have a target it's still not clear how to resolve values?

I think new hooks are needed in one of the base CSS specs (CSS Syntax or CSS Cascade maybe) to specify what it means to parse and resolve a CSS property outside the normal cascade.

Does "outside of the normal cascade" come from setting the range* directly on the animation and not coming from style? So the issue is it's not clear how to these values cascade?

[weinig]

But even if we assume that effect's target is available at times where resolving rangeStart and rangeEnd happens, it's not clear how that should work.

Sorry, I may be out of my element here (none intended), can you explain why when you have a target it's still not clear how to resolve values?

Heh.

What I mean is that there is no specification text that specifies how to take a string, the grammar for a CSS property, and an Element, and produce a TimelineRangeOffset.

I think new hooks are needed in one of the base CSS specs (CSS Syntax or CSS Cascade maybe) to specify what it means to parse and resolve a CSS property outside the normal cascade.

Does "outside of the normal cascade" come from setting the range* directly on the animation and not coming from style?

Yes.

So the issue is it's not clear how to these values cascade?

No. I only mention "outside of the normal cascade", because that is the specified way we know how to resolve things using CSS property grammars. That is, it is well defined how a CSS property in a style rule gets resolved. I can point to spec text that explains how values are resolved, e.g https://www.w3.org/TR/css-cascade-4/#value-stages.