Which style attributes are permitted in animate and set?

[nigelmegitt]

The animate and set elements' content model permits and style attribute in the TT Style Namespace. However:

1. The introduction to the sections on set and animate has been changed to refer to "styling attributes", but the content model does not reflect that. Although this is syntactically correct (since attributes in other namespaces are excluded from the content model and pruned prior to validation) we can do something more useful: I propose adding a comment to the content model highlighting that styling attributes in other namespaces are also considered for processing in the animation semantic, even though they are excluded from the content model from a formal specification perspective.

2. There is no constraint in animate that the specified styling attributes have an "Animatable" specification that includes "continuous" (not sure if "discrete" should be permitted too - I guess there's a fallback to discrete animation even if animate is used, so probably it should be).

3. There is no constraint in set that the specified styling attributes have an "Animatable" specification that includes "discrete".

The key point about 2 and 3 is that attributes that say "Animatable: none" are currently permitted in animate or set, but there is no meaningful semantic, and <animation-value-list> is required to have at least two entries; there is no defined fallback for when the requested animation cannot be performed.

#950 highlighted to me that this could be an issue, for example tts:ruby has Animatable: none.

In terms of processors, I would expect that:

a. a validating processor should reject (or warn?) when a non-animatable styling attribute is present in an animate or set element;
b. a presentation processor must ignore non-animatable styling attributes in an animate or set element.

I couldn't find any spec text to deal with either of those scenarios in the TTML2 ED.

[skynavga]

As far as I'm concerned, this is a non-issue. We also don't prescribe behavior for when an author specifies a non-inheritable property on an element to which the property doesn't apply. See the last (3rd) note in the preamble of 10.2.

As it happens, an (old) issue is logged against TTV to emit such a warning: skynav/ttt#10. There are many other opportunities for validators to emit warnings that are not explicitly mentioned by the spec, such as the following (to cite a few):

• add warning when children active period exceeds parent active period skynav/ttt#186
• support warning for non-required feature skynav/ttt#18
• support warning for non-significant ttm:title skynav/ttt#16
• support warning for non-significant ttm:description skynav/ttt#15
• support warning for non-significant ttm:copyright skynav/ttt#14
• support warning for non-significant ttm:agent skynav/ttt#13
• support warning if tt:set is empty (no style attribute to animate) skynav/ttt#12
• support warning for redundant style attribute skynav/ttt#11
• support warning for poor contrast between foreground and background colors skynav/ttt#9
• support warning for poor colors for impaired viewers skynav/ttt#8
• support warning if end time precedes begin time skynav/ttt#7
• support warning if duration and end time both specified but resolve to different values skynav/ttt#6
• support warning for unreferenced ttm:agent skynav/ttt#5
• support warning for unreferenced tt:region skynav/ttt#4
• support warning for empty tt:layout skynav/ttt#3
• support warning for unreferenced tt:style skynav/ttt#2
• support warning for empty tt:styling skynav/ttt#1

The extent to which a validator emits additional warnings not explicitly mentioned by the specification is a QoI (quality of implementation) matter.

[nigelmegitt]

If this is a non-issue, then both of the following two presentation processor behaviours are conformant when a set element is present that tries to modify the value of tts:ruby (and does nothing else):

1. Implementation attempts to re-present the content with the new value(s) at each discrete time specified by the set element
2. Implementation ignores the set element and keeps the first specified value of tts:ruby

Just to be clear, this is not high on my list of priorities in terms of getting it fixed, but it does seem like an interop issue.

[skynavga]

@nigelmegitt given that tts:ruby is marked as non-animatable, (1) would clearly be non-conformant, while (2) is the only reasonable implementation; from §10.2 preamble:

The term none indicates the style is not animatable.

at present, we don't say that it is invalid for a document to attempt to animate a non-animatable style, or to apply continuous animation when only discrete is allowed; as a consequence, I would expect implementations to ignore such animation specifications, and a validator might want to emit a warning;

[nigelmegitt]

(1) would clearly be non-conformant

I don't believe that is clear, because:

at present, we don't say

@skynavga That's exactly the issue I'm raising here.

[skynavga]

@nigelmegitt I'm have a very difficult time understanding why you think that a rational reader could possibly interpret none to mean not none w.r.t. animation semantics.

[nigelmegitt]

@skynavga Perhaps its because I've seen too many implementers take the view that if it is not explicitly stated as a requirement then they have complete freedom.

[skynavga]

@nigelmegitt doing so would be a direct violation of §3.2.1 Generic Processor Performance (emphasis added)

6. If the processor supports some optional processing semantics defined by this specification, then it does so in a manner consistent with the defined semantics.

the intent of this rule is to serve as a catch-all for such willful stupidity (on the part of the implementer), if I may be so blunt

[skynavga]

After considering this issue further, I have changed my position, and now believe a substantive change is warranted.