Specifying tts:position and tts:origin on the same element should be an error.

[palemieux]

Per #435 (comment)

• The current text breaks the intent for TTML1 documents to be processed by TTML2 processors as they would have been processed by TTML1 processors
• no tts:position user intends to use tts:origin

[nigelmegitt]

The follow-up to that comment explained the rationale for permitting them both on the same element, which I thought made sense. Has something changed since then?

[palemieux]

@nigelmegitt I have updated the issue description

[css-meeting-bot]

The Working Group just discussed Specifying tts:position and tts:origin on the same element should be an error. ttml2#538, and agreed to the following resolutions:

• RESOLUTION: Close this issue without further action on the basis that additional document constraints can be applied in profiles if that is desirable.

The full IRC log of that discussion

<nigel> Topic: Specifying tts:position and tts:origin on the same element should be an error. ttml2#538
<nigel> github: https://github.com//issues/538
<nigel> Pierre: The reason for having both is for compatibility with TTML1 but the document is
<nigel> .. presented differently by a TTML2 processor and a TTML1 processor if the values differ.
<nigel> Glenn: If the author has specified both to present the same result then they will behave the
<nigel> .. same. It's only in the case that neither is present or if the values differ that the behaviours
<nigel> .. would differ. If the values differ that's the author's problem.
<nigel> Pierre: We have created a potential for ambiguity here.
<nigel> Glenn: Consider the region element - percentages matter and you cannot express, without
<nigel> .. knowing the root container, a fixed position of a region.
<nigel> .. For example positioning the region 10% from the bottom of the root container region.
<nigel> Nigel: I don't think that's true.
<nigel> Pierre: [also doesn't believe it]
<nigel> Cyril: 5 cases to enumerate.
<nigel> .. 1. Neither origin nor position specified - TTML1 and TTML2 produce different results because the origin and position attributes have different initial values.
<nigel> Nigel: How do you know it's a TTML2 document in that case?
<nigel> Pierre: If you consider a TTML1 document is a TTML document that does not contain TTML2 features...
<nigel> Nigel: You might not know from looking at the document.
<nigel> Cyril: 2. Only origin specified.
<nigel> .. 3. Only position specified.
<nigel> 4. Both origin and position specified.
<nigel> s/d./with the same intended result.
<nigel> s/4/.. 4
<nigel> Cyril: 5. Both origin and position specified with different intended results.
<nigel> Pierre: 2 and 3 are the easiest. In 2 the outcome is the same for both TTML1 and TTML2 processors.
<nigel> Cyril: We may have to change the design from what we said yesterday to say that TTML1
<nigel> .. documents are only processed the same if they do not contain TTML2 features.
<nigel> Nigel: Case 3 means a TTML1 processor will use the initial value of origin.
<nigel> Pierre: Yes but the author has no expectation there.
<nigel> Glenn: For 4 I assume the TTML1 processor will use origin and the TTML2 processor will
<nigel> .. use position and they will have the same result.
<nigel> Pierre: From an authorial standpoint you don't need 4.
<nigel> Glenn: It's okay with me if the author wants to do 5 but its undesirable.
<nigel> Cyril: For 4, you get the same processing on both.
<nigel> Pierre: It complicates the spec for no benefit, having to deal with the precedence rules.
<nigel> Glenn: The alternative is that you tell the author what not to do and fail to define the
<nigel> .. processor behaviour then that processor behaviour is undefined so you're introducing
<nigel> .. an ambiguity.
<nigel> Cyril: Talking about 1, what does it mean, that we have to change the initial value for position?
<nigel> Pierre: Yes
<nigel> Glenn: In that case if neither is present maybe it should use origin in the absence of any
<nigel> .. reason to choose TTML2 semantics.
<nigel> Nigel: Can't we simply change the initial value of position to "top left"?
<nigel> Cyril: I think there are lots of instances where initial values of position are used.
<nigel> Glenn: Position is also used for image and background image and for consistency with CSS
<nigel> .. it has an initial value of "center".
<nigel> Cyril: I would agree with Glenn that if the effective processor profile is TTML2 then use
<nigel> .. position, or if it is TTML1 then use origin.
<nigel> Glenn: [slaps own hand] tts:position only applies to region, not to tt at all, and it is not used
<nigel> .. directly for background. What we have is a backgroundPosition attribute which is different.
<nigel> Cyril: Scoping the problem, this is applicable only on region.
<atai2> q+
<nigel> ack atai
<nigel> Andreas: Following the discussion I would be concerned if a document with neither origin
<nigel> .. nor position present would lead to a different result for TTML1 and TTML2 processors.
<nigel> .. The signalling of profile is not a big help. We should make sure this document will be
<nigel> .. rendered the same by both processor.
<nigel> Nigel: So make the initial values coincident?
<nigel> Andreas: Definitely.
<nigel> Cyril: That goes against CSS alignment.
<nigel> Glenn: Our use of position with region is different than its CSS use with image, so we can
<nigel> .. have a different initial value. But let me point out that we have an initial element.
<nigel> Pierre: Netflix's real usage is an important data point which I would like to wait for.
<nigel> Cyril: I will check.
<nigel> Pierre: There's a thread going on where they point out that the three component value
<nigel> .. of the CSS position property can lead to syntactic ambiguities. Why do we support up
<nigel> .. to 4 value components?
<nigel> Glenn: They had those in CSS - if they have taken them out then I don't know about that.
<nigel> .. If there's an ambiguity we have called that out and resolved it in our spec.
<nigel> Nigel: I recall reviewing that and checking there was no ambiguity.
<nigel> Pierre: Perhaps we can help with alignment and avoiding bugs by changing to follow the CSS change.
<nigel> Nigel: Is the reduced syntax version of the CSS property in a spec in the current CSS snapshot?
<nigel> Pierre: I will find the thread.
<pal_> https://github.com/w3c/csswg-drafts/issues/2140
<nigel> Cyril: Propose to defer this question about the position property and attribute until the next call.
<nigel> Nigel: Going back to this issue... The proposal is to prohibit both origin and position being
<nigel> .. present and remove the precedence rule.
<nigel> Pierre: We can have a fallback precedence rule as well.
<nigel> Glenn: I could live with that as a required error behaviour.
<nigel> Pierre: I don't want to force a specific processor behaviour for handling an error condition.
<nigel> Cyril: Previously it was not an error condition.
<nigel> Glenn: I object to making it an error in documents.
<nigel> Pierre: I'm trying to propose something like the behaviour in <timeExpression> where it
<nigel> .. is considered an error if some value formats are used.
<nigel> Glenn: I have an action to go through the whole spec explaining processor behaviour if
<nigel> .. an error is encountered. What you are suggesting is to make a document non-conformant
<nigel> .. if both origin and position are present. I don't like it because you don't know what the
<nigel> .. target processor will be.
<nigel> Nigel: Would a possible compromise be to define the behaviour with both present in TTML2
<nigel> .. and then if desirable prohibit them both being present in a profile?
<nigel> Pierre: Yes, I'm trying to keep IMSC 1.1 as simple as possible, but that would work.
<nigel> Glenn: I would accept.
<nigel> Cyril: OK
<nigel> Pierre: We still have to solve the initial value problem.
<nigel> RESOLUTION: Close this issue without further action on the basis that additional document constraints can be applied in profiles if that is desirable.