Re: Format of animatable value for color only properties

> 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"? 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>, 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" />


>> 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?

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?


> 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"?
2. So a multi-component property (like <border>) should have only the <color> in the expression, because it allows so (thought the OR). But are you considering also <text-outline> as a multi-component as well? 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)
<animate tts:textOutline="red 10px 10px; blue 12px 10px; green 12px 14px" /> (was invalid)


Thank you,
Alexander


> Il giorno 11 mar 2025, alle ore 01:38, Glenn Adams <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