Re: Format of animatable value for color only properties

On Wed, Mar 12, 2025 at 1:14 PM Alexander Cerutti <
cerutti.alexander@gmail.com> wrote:

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

Sorry, this was a typo, since, as I have stated elsewhere, each value must
be syntactically valid according to the property definition. The correct
usage would have to be:

<animate tts:textOutline="red 10px 10px; green 10px 10px; blue 10px 10px"/>

One might think that you could use

<animate tts:textOutline="red 10px 10px; green 10px; blue 10px"/>

However, this would imply a continuous change for the blur radius, since if
blur radius is not specified, 0px is used per the spec.


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

 Only the second of these would be valid.


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