search

w3c / ttml2

Timed Text Markup Language 2 (TTML2)
https://w3c.github.io/ttml2/
Other
41 stars 16 forks source link

Which style attributes are permitted in animate and set? #1153

Closed nigelmegitt closed 4 years ago

nigelmegitt commented 5 years ago

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 commented 5 years ago

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: https://github.com/skynav/ttt/issues/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):

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

nigelmegitt commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

(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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

  1. 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 commented 5 years ago

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