Do not default to px units in the absence of units on a <length> expression.

[nigelmegitt]

TTML2 differs from TTML1 in the treatment of <length> units with no unit. TTML1 says:

It is an error to omit the units component of a scalar length value.

TTML2 currently says:

If no units component is specified in a <length> expression, then it is to be treated as if px (pixels) units were specified.

However, we are in general attempting to converge with CSS, and in CSS some properties treat lengths without units (which are not <length> but are <number>) as multipliers to be evaluated on the element to which they are being applied. For example this is used in the line-height property.

By creating a behaviour for when no units component is specified in a <length> expression it becomes indistinguishable from <number> and therefore prevents our future potential adoption of this CSS approach. I propose to revert this change in TTML2 in favour of the TTML1 approach so that we are able to use unitless numbers in style attributes that take lengths at some point in the future.

Further motivation for this reversion comes from #330 - the resolution to that issue means that omitting a unit generates the pixel behaviour which now means there should be a tts:extent on the tt root element, however it is much harder to test for since the document may have no explicit mention of px at all and still generate a warning/error condition if that attribute is absent and a unitless length is used.

[css-meeting-bot]

The Working Group just discussed Do not default to px units in the absence of units on a `<length>` ttml2#561, and agreed to the following resolutions:

• RESOLUTION: Revert to prohibit use of `<length>` without units.

The full IRC log of that discussion

<nigel> Topic: Do not default to px units in the absence of units on a `<length>` ttml2#561
<nigel> github: https://github.com/w3c/ttml2/issues/561
<nigel> Glenn: We had introduced a default unit in TTML2 to match what was in SVG. You make a
<nigel> .. case for not using it because it makes the potential use of a `<number>` as a syntactic
<nigel> .. element problematic in the case that some property admits both length and number as
<nigel> .. values. I don't think we have any of those right now but we could do in the future.
<nigel> .. TTT implements this but I'm not wedded to it strongly enough to insist on it staying in.
<nigel> .. We don't use `<number>` with lineHeight for example.
<nigel> Nigel: This issue has 2 thumbs up.
<nigel> Glenn: It will be a substantive change [adds the label]
<nigel> RESOLUTION: Revert to prohibit use of `<length>` without units.

[skynavga]

I have reviewed this in more detail, and some comments are in order:

• there are no cases in TTML2 where a parsing ambiguity would arises if units are not specified on a length expression; which is to say, there is no context where a <non-negative-integer> or an <integer> may appear in the same context as <length>;

• CSS 3 Units and Values [1] allows unit-less length expressions for the value of 0;

[1] https://drafts.csswg.org/css-values/#length-value

• code that parses lengths and code that checks if a pixel value is present without tts:extent on tt is not complicated by the lack of explicit marking of px, since if it supplies px by default, it will still (and easily) be able to detect it as a use of a pixel based length;

• the TTV verifier already implements such px defaulting logic (when using ttml2 model) and detection of px usage (when using imsc1 model), so no implementation issue is anticipated with maintaining the currently defined defaulting behavior while adding warnings for the lack of tts:extent when using explicit or defaulted pixel units;

I would suggest we modify our resolution to follow CSS and allow eliding units only when the length is equal to zero.

[palemieux]

CSS states "if a 0 could be parsed as either a <number> or a <length> in a property (such as line-height), it must parse as a <number>." Since <number> is not supported in TTML2, I do not see how it is possible to match CSS3.

In any event, if <length> expressions are extended in TTML2. a matching feature needs to be defined.

[skynavga]

@palemieux regarding

CSS states "if a 0 could be parsed as either a <number> or a <length> in a property (such as line-height), it must parse as a <number>." Since <number> is not supported in TTML2, I do not see how it is possible to match CSS3.

Of course it matches (at least now), since 0 could never be parsed as a <number> in the context of using <length> (in TTML2). However, in the future, that could change, in which case the CSS3 language would work as well (if we adopt it).

In any event, if <length> expressions are extended in TTML2. a matching feature needs to be defined.

Agreed.

[skynavga]

@nigelmegitt your opinion?

[nigelmegitt]

Since <number> is not supported in TTML2, I do not see how it is possible to match CSS3.

@palemieux If I've read it correctly, your point is that by allowing an unqualified number when the value is 0, if that value were passed unmodified to a CSS processor, it could be treated differently to its intended meaning in TTML2, which would have an implied unit. In general I would prefer not to make a special case for 0, and this argument is somewhat persuasive that we should require the unit in all cases including 0, since we do not currently permit <number>.

I don't think it is contentious, but just to be clear, the point of this issue is to avoid blocking a potential future adoption of <number> in TTML, so I'm not swayed by an argument of the form "<number> is not supported in TTML2, so there is no current ambiguity", since that applies now and is not forward looking. I'm considering the complexity of specifying how future TTMLv.n processors that (hypothetically) support <number> should handle a TTML2 document that uses default units on <length>s and I would rather not even open up the possibility. Nor do I see any need to.

I would suggest we modify our resolution to follow CSS and allow eliding units only when the length is equal to zero.

@skynavga In summary, I do not think we should modify the resolution in this way at this time.

[skynavga]

@nigelmegitt your logic is wrong

[palemieux]

@skynavga Where is @nigelmegitt 's wrong?

[skynavga]

@palemieux @nigelmegitt context sensitivity in CSS is irrelevant in the TTML context;

[palemieux]

@skynavga You made CSS relevant in https://github.com/w3c/ttml2/issues/561#issuecomment-360921885

I see many more downsides than upsides to making a substantive departure from TTML1 so close to CR, and recommend we stick to the resolution at this point and revisit increases compatibility with CSS in TTMLvNEXT.

[skynavga]

The decision to support unit-less pixels is about 3 to 5 years old now, and has already been implemented in TTV (for validation) and TTPE (for presentation).

[palemieux]

@skynavga As far as I know, the decision to adopt unitless measures was unilateral by the editor, not based on any specific requirement and/or issue, and not accompanied by a feature definition that allows profile to forbid these new semantics, which are not compatible with CSS. This issue asks that this decision be reverted, which I agree with.

[palemieux]

I did some digging. Unitless <length> was introduced as part of 4f9fa5cab apparently to support the stereoRight and stereoLeft named metadata items, which have since been superseded by tts:disparity, which does not use unitless <length>.

[skynavga]

The specific change to unitless is at https://github.com/w3c/ttml2/commit/2764d2d89427a9d5935d1bd1dadd026898287452. This appears to be driven by https://www.w3.org/AudioVideo/TT/tracker/issues/224.

[skynavga]

Although I believe it is safe to retain unit-less lengths for 0, which is already implemented and is compatible with CSS3, I won't insist on doing so, so have just filed a PR (#595) that removes unit-less lengths entirely. I will label as ttml.next for consideration of restoring in a future version.

[nigelmegitt]

Thanks @skynavga , appreciated.

[skynavga]

There appears to be no imperative to proceed with this issue, so I'm closing at this time. If a need does materialize, then we can resurrect this issue.