Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nigelmegitt opened this issue Jan 15, 2018 · 17 comments
Closed
Labels

Comments

@nigelmegitt
Copy link

@nigelmegitt nigelmegitt commented Jan 15, 2018

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.

@skynavga skynavga self-assigned this Jan 18, 2018
@css-meeting-bot

This comment has been minimized.

Copy link
Member

@css-meeting-bot css-meeting-bot commented Jan 18, 2018

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 skynavga changed the title Do not default to px units in the absence of units on a `<length>` Do not default to px units in the absence of units on a <length> expression. Jan 19, 2018
@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 26, 2018

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

This comment has been minimized.

Copy link

@palemieux palemieux commented Jan 27, 2018

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

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 27, 2018

@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

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 27, 2018

@nigelmegitt your opinion?

@nigelmegitt

This comment has been minimized.

Copy link
Author

@nigelmegitt nigelmegitt commented Jan 28, 2018

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

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 28, 2018

@nigelmegitt your logic is wrong

@palemieux

This comment has been minimized.

Copy link

@palemieux palemieux commented Jan 28, 2018

@skynavga Where is @nigelmegitt 's wrong?

@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 28, 2018

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

@palemieux

This comment has been minimized.

Copy link

@palemieux palemieux commented Jan 28, 2018

@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

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 28, 2018

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

This comment has been minimized.

Copy link

@palemieux palemieux commented Jan 28, 2018

@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

This comment has been minimized.

Copy link

@palemieux palemieux commented Jan 28, 2018

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

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 28, 2018

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

skynavga referenced this issue in w3c/ttml2 Jan 29, 2018
@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jan 29, 2018

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

This comment has been minimized.

Copy link
Author

@nigelmegitt nigelmegitt commented Jan 29, 2018

Thanks @skynavga , appreciated.

skynavga referenced this issue in w3c/ttml2 Feb 11, 2018
Remove support for unitless lengths (#561).
@skynavga skynavga removed their assignment Feb 11, 2018
@skynavga skynavga reopened this Aug 30, 2018
@skynavga skynavga transferred this issue from w3c/ttml2 Feb 1, 2019
@skynavga skynavga added the substantive label Feb 1, 2019
@skynavga skynavga added this to the 1ED-FPWD milestone Feb 1, 2019
@skynavga

This comment has been minimized.

Copy link
Collaborator

@skynavga skynavga commented Jun 7, 2019

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.

@skynavga skynavga closed this Jun 7, 2019
@skynavga skynavga removed this from the 1ED-FPWD milestone Jun 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.