Re: Format of animatable value for color only properties

> Another example, which should NOT be treated as an error is
> 
> <animate tts:textOutline="red 10px 10px; blue; green"/>
> 
> since it does not imply a change for thickness or blur radius components (in the second and third animation values).

Which seems to be kind of counter intuitive to me, especially for what concerns the blue and green <animation-value>.

I mean, I would expect this to be an error, because (in the case of tts:textOutline) color is an optional attribute, so I'd expect at least the mandatory attributes for the targeted style (tho, repeated - otherwise is an error).
But I see what you mean: what is the sense of repeating attributes that won't (must not) change with a continuous animation?

I would totally agree with you IF the animatable attributes would be mandatory in the style expression.

>> You are fine with allowing non-continuously-animatable property components (like border width) if there is no implication of continuously adjusting such value?
> 
> I believe that is what I said.

Okay, it wasn't exactly clear what you meant by "no implication", but according to the context in this discussion, I understand now that you still referenced about the fact that discretely animatable attributes (with a continuous animation) should not change at all, like we said previously.

> I'm not sure what you mean by <shadow>. Are you asking about animating color on the textShadow property?

Exactly. I was comparing the different rules and what an <animation-value-list> should contain in each <animation-value> for each property.

In the case of <shadow>, from the <text-shadow>, the component <color> is optional and at the end of the expression.

So, according to what I understood until now, with a tts:textShadow in the animation, in order for it to be valid, it must be one of these two:

<animation tts:textShadow="10% -20% 5% red; green; blue"> (however, this could be invalid, see below)
<animation tts:textShadow="10% -20% 5% red; 10% -20% 5% green; 10% -20% 5% blue">

Therefore, we are saying that in an <animation-value-list> for a style property that contains at least one continuously-animatable component, each <animation-value> could contain exclusively the continuously-animatable property instead of the full syntax (so, either this, or the full rule with the discrete values unchanged), even if this implies to not respect the exact position in the style syntax? (continues below).

>> The overriding constraint here is that each value in an animation value list must adhere to the syntax animated style property. This rules out a number of your options below.
> 

> I meant to say "syntax of the animated style property", i.e., each value of an <animation-value-list> must satisfy the syntax prescribed for that value as determined by the style property whose value is expressed as an <animation-value-list>.

I think I got it and that you are referring to this paragraph of the specs:

"The syntax of an <animation-value> in an <animation-value-list> expression must satisfy all syntax requirements that apply to the attribute targeted by the animation."

However, what I still don't understand is: if a style property determines a specific syntax that should be used when defining the style itself, both for animation and normal usage (all components, optionals included or excluded), and such syntax should be used for each <animation-value> (as you and the specs are saying) in a <animation-value-list>, how can specifying only the color be considered valid for properties that do not specify the OR (so <text-outline> and <text-shadow>)?

I feel like the first animation example above for <text-shadow> should be considered invalid instead, but I based it on the one of textOutline you provided me previously (see below).

> Another example, which should NOT be treated as an error is
> 
> <animate tts:textOutline="red 10px 10px; blue; green"/>
> 
> since it does not imply a change for thickness or blur radius components (in the second and third animation values).


Thank you again,
Alexander

> Il giorno 12 mar 2025, alle ore 00:19, Glenn Adams <glenn@skynav.com> ha scritto:
> 
> 
> 
> On Tue, Mar 11, 2025 at 2:46 PM Alexander Cerutti <cerutti.alexander@gmail.com <mailto:cerutti.alexander@gmail.com>> wrote:
>>> The overriding constraint here is that each value in an animation value list must adhere to the syntax animated style property. This rules out a number of your options below.
>> 
>> Could you please expand on what you exactly mean for "syntax animated style property"?
> 
> I meant to say "syntax of the animated style property", i.e., each value of an <animation-value-list> must satisfy the syntax prescribed for that value as determined by the style property whose value is expressed as an <animation-value-list>.
> 
>  
>> You perhaps mean <animation-value> or the Animatable row in the properties tables or what else that I'm not getting? I gave a look in the specs for "animated style property" as well as in the SVG 1.1 standard but couldn't find what is the actual syntax you are referring to.
>> 
>>> Can't ignore, so illegal. 
>> 
>> Got it, won't propose ignoring property components any longer.
>> 
>> 
>>>> Considering the outcome of above, IMO having two different formats for each element of the <animation-value-list>, between (<border>, <text-emphasis>) and  (<text-outline>, <shadow>) for each would create a confusing situation.
>>>> 
>>>> In the second group, the non-continuously-animatable properties in each <animation-value> would get ignored (or treated as discrete) - and I think there is not other way.
>>> 
>>> Can't ignore if specified.
>> 
>> So, if we take for example an animation of<text-outline> like this:
>> 
>> <animate tts:textOutline="red 10px 10px; blue 10px 10px; green 10px 10px" />
>> 
>> This is be fine because there are no changes between the various <length>
> 
> correct, it should NOT be treated as an error
>  
>> but this one wouldn't be fine and should throw an error, isn't it?
>> 
>> <animate tts:textOutline="red 10px 10px; blue 12px 10px; green 12px 14px" />
> 
> correct, it SHOULD be treated as an error
> 
> Another example, which should NOT be treated as an error is
> 
> <animate tts:textOutline="red 10px 10px; blue; green"/>
> 
> since it does not imply a change for thickness or blur radius components (in the second and third animation values).
> 
>  
>> 
>> 
>>>> In the first group, instead, the non-continuously-animatable properties would be forbidden.
>>> 
>>> I'm fine with allowing the non-continuously-animatable property components (not properties) provided there is no implication of continuously adjusting a component's value (such as border width).
>> 
>> I'm sorry, there is something that is short-circuiting in my mind by reading this phrase, so I cannot understand its exact meaning.
>> 
>> You are fine with allowing non-continuously-animatable property components (like border width) if there is no implication of continuously adjusting such value?
> 
> I believe that is what I said.
>  
>> 
>> You mean this would be something depending from property to property and only if (like, at presentation level) everything doesn't get disrupted or what other kind of implications you have in mind?
> 
> The determination of which components in a multiple-component style property's value is dependent upon the style property, so, yes, it will vary. The validity can be determined prior to presentation time.
>  
>> 
>> 
>>> Just follow these rules:
>>> 
>>> 1. if a value of an animation value list is syntactically invalid, then the animation is invalid
>>> 2. if a property component in a multi-component property value in an animation value list implies a continuous change from another value and that component is not continuously animatable, then the animation is invalid
>>>  
>> 
>> 
>> 1. "a value of an animation value list", which is the definition of the style itself, right? Or you mean the what you mentioned above "syntax animated style property"?
> 
> See above.
>  
>> 2. So a multi-component property (like <border>) should have only the <color> in the expression
> 
> No, that's not what rule 2 says. It can contain a border style and border width component provided no change of value is implied. For example, (1) specify the non-changing components in the first animation value, or (2) repeat the non-changing components in each animation value.
>  
>> , because it allows so (thought the OR). But are you considering also <text-outline> as a multi-component as well?
> 
> Yes, textOutline is multi-component, because it allows or requires one to specify multiple component values that have distinct semantics. For example, textOutline has an optional color component, a required length component, and a second, optional, length component. Per definition, the color component is continuously animatable, while the length components are only discretely animatable. If one were to combine all three components in an <animate> element with a calcMode other than discrete, then the length components cannot be animated continuously, as would be implied by something like:
> 
> <animate tts:textOutline="red 10px; green 20px"/>
> 
> which has an implied linear calcMode.
>  
>> Just to be on the same page. Because if you are considering <text-outline> a multi-component, then tts:Outline cannot be animated at all to me, because that would mean that the example i wrote above (and that I'm reporting here below), is invalid... unless there you can only specify the <color> - but otherwise, this would mean that in case of <shadow>, you can specify only the <color> as well, even if at the end of the list of components?
>> 
>> <animate tts:textOutline="red 10px 10px; blue 10px 10px; green 10px 10px" /> (was valid)
> 
> This is valid, as I detail above.
>  
>> <animate tts:textOutline="red 10px 10px; blue 12px 10px; green 12px 14px" /> (was invalid)
> 
> This is not valid, since it implies a linear change to both thickness and blur radius components (calcMode defaults to linear).
> 
> I'm not sure what you mean by <shadow>. Are you asking about animating color on the textShadow property?
>  
>> 
>> 
>> Thank you,
>> Alexander
>> 
>> 
>>> Il giorno 11 mar 2025, alle ore 01:38, Glenn Adams <glenn@skynav.com <mailto:glenn@skynav.com>> ha scritto:
>>> 
>>> 
>>> 
>>> On Mon, Mar 10, 2025 at 7:03 PM Alexander Cerutti <cerutti.alexander@gmail.com <mailto:cerutti.alexander@gmail.com>> wrote:
>>>> Hi Glenn,
>>>> thank you for your reply.
>>>> 
>>>> For what concerns specifically <border> and <text-emphasis>, both Option #1 and Option #2 sound quite chaotic to me, in terms of parsing and understanding the attributes on different levels, but I understand how such situations COULD be possible to encounter, as both styles are defined as a unordered non-repeated set of properties (in "OR").
>>>> 
>>>> However, this doesn't seem to not apply to <text-outline> and <text-shadow>, as both have <color> in a specific position, even if optional.
>>>> 
>>>> 
>>>> 
>>>> <text-outline> = (<color> <lwsp>)? <length> (<lwsp> <length>)?
>>>> 
>>>> <text-shadow> = <shadow> (<lwsp>? "," <lwsp>? <shadow>)*
>>>> 
>>>> <shadow> = <length> <lwsp> <length> (<lwsp> <color>)?   |   ...
>>>> 
>>>> 
>>>> 
>>>> I have a doubt: is there any possible "limit" or rule for which an expression that doesn't have any "||" (OR) could be splitted and still remain valid in the context of animation? I don't think so, but I wouldn't wonder if I missed it in the specification.
>>>> 
>>>  
>>> The overriding constraint here is that each value in an animation value list must adhere to the syntax animated style property. This rules out a number of your options below.
>>>  
>>>> I feel like in Option #1, <text-outline> and <text-shadow> would require the whole expression repeated "again and again" after semicolons, as <color> is optional but <length> isn't. Furthermore, <color> has a specific position.
>>>> 
>>>> So, unless (at least for what concerns <text-outline>), the animation expression is considered still valid when limited to the (originally optional) <color>, I think what I wrote above applies.
>>>> 
>>>> Allowing <text-outline> to work with Option #1 would mean to have something like:
>>>> 
>>>> 
>>>> <animate tts:textOutline="red; green; blue 10px" />
>>>> 
>>>> or
>>>> 
>>>> <animate tts:textOutline="red 10px 10px; blue 10px 10px; green 10px 10px" />
>>>> 
>>>> 
>>>> And of these two, I feel like the second is the one that should be used, unlike <text-shadow>, for which having <color> as the last attribute of <shadow>, doesn't even allow to think to the first possibility.
>>>> 
>>>> In the second option, of course, discrete attributes (<length>) would get completely ignored or animated as discrete (this applies as well to the Option #2).
>>>> 
>>>>>> or
>>>>>> 
>>>>>> tts:border="2px solid red; green; blue"
>>>>>> 
>>>>> 
>>>>> This too is arguably well-defined since it does not imply a transition for border width or border style, and each value in the animation value list adheres to the syntax of tts:border.
>>>> 
>>>> So, according to the non-specific order of elements in <border> and <text-emphasis> AND the composition of <animation-value-list>, would you consider these valid as well?
>>>> 
>>>> tts:border="red; green; blue 2px solid"
>>> 
>>> If the style and width is otherwise specified as "solid 2px", then yes; otherwise, no, if calcMode is linear, paced, spline.
>>>  
>>>> tts:border="solid red; green; blue 2px"
>>> 
>>> If the style and width is otherwise specified as "solid 2px", then yes; otherwise, no, if calcMode is linear, paced, spline.
>>>   
>>>>  
>>>> 
>>>> Note that there are no semicolons between animation attributes list and the rest.
>>>> Supporting these possibilities, sounds very chaotic... still doable, but chaotic in terms of understanding what is what.
>>>> 
>>>>>> Furthermore, assuming the first case is the right one or at least one of the two supported, let's take the following example:
>>>>>> 
>>>>>> 
>>>>>> tts:border="2px solid red; 5px solid green; 10px dashed blue"
>>>>>> 
>>>>> 
>>>>> I would consider this to be not well defined (an error) if specified on an animate element, since it implies a linear animation of border width and border style (the default calcMode is linear).
>>>> 
>>>> 
>>>> Unless ignoring the non continuously-animatable attributes changes (or treat them as discrete even if calcMode is a continuous one).
>>> 
>>> Can't ignore, so illegal. This applies to the following questions/options as well.
>>>  
>>>> 
>>>> Considering the outcome of above, IMO having two different formats for each element of the <animation-value-list>, between (<border>, <text-emphasis>) and  (<text-outline>, <shadow>) for each would create a confusing situation.
>>>> 
>>>> In the second group, the non-continuously-animatable properties in each <animation-value> would get ignored (or treated as discrete) - and I think there is not other way.
>>> 
>>> Can't ignore if specified.
>>>  
>>>> In the first group, instead, the non-continuously-animatable properties would be forbidden.
>>> 
>>> I'm fine with allowing the non-continuously-animatable property components (not properties) provided there is no implication of continuously adjusting a component's value (such as border width).
>>>  
>>>> 
>>>> Then, there might be some other situations and properties that we might not be considering that might change everything.
>>> 
>>> Just follow these rules:
>>> 
>>> 1. if a value of an animation value list is syntactically invalid, then the animation is invalid
>>> 2. if a property component in a multi-component property value in an animation value list implies a continuous change from another value and that component is not continuously animatable, then the animation is invalid
>>>  
>>>> 
>>>> Thank you,
>>>> Alexander
>>>> 
>>>> 
>>>>> Il giorno 10 mar 2025, alle ore 03:40, Glenn Adams <glenn@skynav.com <mailto:glenn@skynav.com>> ha scritto:
>>>>> 
>>>>> Hi Alexander,
>>>>> 
>>>>> Thanks for asking these excellent questions. It certainly wouldn't hurt to elaborate on this matter in a future edition of TTML2. See my inline comments below for details.
>>>>> 
>>>>> On Sat, Mar 8, 2025 at 2:39 PM Alexander Cerutti <cerutti.alexander@gmail.com <mailto:cerutti.alexander@gmail.com>> wrote:
>>>>>> Hello,
>>>>>> I was facing the introduction of discrete and continuous animations in my ttml engine.
>>>>>> 
>>>>>> I saw animate tag requires style-namespace properties to adhere to the <animation-value-list> and then the <animation-value> properties.
>>>>>> 
>>>>>> So, for example, for what concerns tts:color, we can have something like this (took from specs):
>>>>>> 
>>>>>> <animate xml:id="a1" keyTimes="0;0.2;1" tts:color="red;green;blue"/>
>>>>>> 
>>>>>> In the definitions of animatable styles, I saw some that are not exactly clear and for which I found no tests nor examples.
>>>>>> 
>>>>>> These following properties, report the "color only" marker on the "Animatable" row:
>>>>>> 
>>>>>>  - tts:border
>>>>>>  - tts:textEmphasis
>>>>>>  - tts:textOutline
>>>>>>  - tts:textShadow
>>>>>> 
>>>>>> As their color is animatable, I was wondering about the following details:
>>>>>> 
>>>>>> 1) the "color only" applies only on continuous animation, so either on <set> element or <animate> with calcMode = "linear" | "paced" | "spline". Is this correct?
>>>>> 
>>>>> Yes, though continuous animation doesn't apply to the set element.
>>>>>  
>>>>>> 2) What is the syntax that one should write when, for example, tts:border is animated? Reporting all the attributes for each keyTime? For example:
>>>>>> 
>>>>>> tts:border="2px solid red; 2px solid green; 2px solid blue"
>>>>> 
>>>>> This is arguably well defined, since it does not imply a change to border width or style.
>>>>> 
>>>>> To accomplish this, I would use one of two approaches:
>>>>> 
>>>>> Option #1 - set fixed, non-animated styles as default border style, animating color only
>>>>> 
>>>>> <p tts:border="2x solid">
>>>>>   <animate tts:border="red; green; blue"/>
>>>>>   A paragraph with a 2px, solid border with a linear animated border color transitioning from red to green to blue
>>>>>   over implied keyTimes="0;0.5;1".
>>>>> </p>
>>>>> 
>>>>> Option #2 - use a combination of discrete (set) and continuous (animate) animation elements
>>>>> 
>>>>> <p>
>>>>>   <set tts:border="2x solid"/>
>>>>>   <animate tts:border="red; green; blue"/>
>>>>>   A paragraph with a 2px, solid border with a linear animated border color transitioning from red to green to blue
>>>>>   over implied keyTimes="0;0.5;1".
>>>>> </p>
>>>>> 
>>>>> There are other ways to accomplish this as well, such as using out-of-line animation.
>>>>> 
>>>>>> 
>>>>>> or
>>>>>> 
>>>>>> tts:border="2px solid red; green; blue"
>>>>>> 
>>>>> 
>>>>> This too is arguably well-defined since it does not imply a transition for border width or border style, and each value in the animation value list adheres to the syntax of tts:border.
>>>>>  
>>>>>> In my ignorance, both could be fine (even the second sounds weird, if I give a look at <animation-value-list>)
>>>>> 
>>>>> IMO, yes.
>>>>>  
>>>>>> 
>>>>>> 
>>>>>> Furthermore, assuming the first case is the right one or at least one of the two supported, let's take the following example:
>>>>>> 
>>>>>> 
>>>>>> tts:border="2px solid red; 5px solid green; 10px dashed blue"
>>>>>> 
>>>>> 
>>>>> I would consider this to be not well defined (an error) if specified on an animate element, since it implies a linear animation of border width and border style (the default calcMode is linear).
>>>>>  
>>>>>> 
>>>>>> I see three possible outcomes with this expression, when a continuous calcMode is used:
>>>>>> 
>>>>>> - this is an error: only color should be supported
>>>>>> - this is valid but only color is kept in consideration: when the keyTimes progresses, we'll have both "2px solid green" and "2px solid blue"
>>>>>> - this is valid but only color is animated continuously. The rest of the properties are animated discreetly.
>>>>>> 
>>>>>> Which of the above is correct?
>>>>> 
>>>>> See my responses above. Note that a good point raised by your questions is what does it mean if multiple animation styles independently set or animate different components of a multi-component style property (such as tts:border). I don't recall the group (or myself) discussing this previously.
>>>>> 
>>>>>> 
>>>>>> Thank you very much for your support,
>>>>>> Alexander