- From: Alexander Cerutti <cerutti.alexander@gmail.com>
- Date: Tue, 11 Mar 2025 01:07:19 +0100
- To: public-tt@w3.org
- Message-Id: <8023FA2A-922B-47C5-A775-855476B9A15A@gmail.com>
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. 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" tts:border="solid red; green; blue 2px" 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). 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. In the first group, instead, the non-continuously-animatable properties would be forbidden. Then, there might be some other situations and properties that we might not be considering that might change everything. 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 <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 >
Received on Tuesday, 11 March 2025 00:07:36 UTC