Re: Format of animatable value for color only properties

On Tue, Mar 11, 2025 at 2:46 PM Alexander Cerutti <
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> ha
> scritto:
>
>
>
> On Mon, Mar 10, 2025 at 7:03 PM Alexander Cerutti <
> 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> 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> 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
>>>
>>
>