Remove application of tts:rubyPosition to ruby annotation text.

[palemieux]

TTML2 currently specifies that tts:rubyPosition applies to textContainer or text

CSS ruby-position applies to ruby annotations containers, i.e. ruby and rtc.

Is there a reason for that divergence? I couldn't find any. If there is no specific reason, TTML2 should be aligned to CSS, and the applicability of tts:rubyPosition should be container or textContainer.

<span tts:ruby="container">
  <span tts:ruby="base">利用許諾</span>
  <span tts:ruby="text"  tts:rubyPosition="after">ライセンス</span>
</span>

becomes

<span tts:ruby="container"  tts:rubyPosition="after">
  <span tts:ruby="base">利用許諾</span>
  <span tts:ruby="text">ライセンス</span>
</span>

but the following remain unchanged:

<span>
  <span tts:ruby="container" tts:rubyAlign="spaceAround">
    <span tts:ruby="baseContainer">
      <span tts:ruby="base">東南</span>
    </span>
    <span tts:ruby="textContainer" tts:rubyPosition="before">
      <span tts:ruby="text">とうなん</span>
    </span>
    <span tts:ruby="textContainer" tts:rubyPosition="after">
      <span tts:ruby="text">たつみ</span>
    </span>
  </span>
  <span>の方角</span>
</span>

See also #832

[skynavga]

According to the current ED of CSS Ruby Layout Module 1 [1], a ruby annotation container includes only rtc, but does not include ruby (from HTML5 element types). In TTML2, rtc corresponds with tts:ruby="textContainer". So we are fine there. However, how to specify position when there is no explicit ruby text container? The CSS module doesn't appear to support that usage; however, TTML2 does by allowing rubyPosition on tts:ruby="text", effectively rt in the HTML5 element vocabulary. Further, if there are two tts:ruby="text" in a single ruby container (tts:ruby="container"), then they must resolve to the same value. This maps cleanly to an implied ruby text container with the same position.

Therefore, there is no semantic mapping problem as far as I can see. If you want to map to HTML5/CSS, then simply map

<span tts:ruby="container">
  <span tts:ruby="base">利用許諾</span>
  <span tts:ruby="text"  tts:rubyPosition="after">ライセンス</span>
</span>

to

<span tts:ruby="container">
  <span tts:ruby="baseContainer"><span tts:ruby="base">利用許諾</span></span>
  <span tts:ruby="textContainer" tts:rubyPosition="after"><span tts:ruby="text">ライセンス</span></span>
</span>

Note that we already have language that requires such processing: see the last paragraph of 10.2.35.1.

[1] https://drafts.csswg.org/css-ruby-1/

[palemieux]

According to the current ED of CSS Ruby Layout Module 1 [1], a ruby annotation container includes only rtc, but does not include ruby (from HTML5 element types).

The HTML specification implies that ruby is a container since it contains rt elements.

However, how to specify position when there is no explicit ruby text container? The CSS module doesn't appear to support that usage;

This is done by specifying ruby-position on ruby:

https://codepen.io/palemieux/pen/PBExEW

Therefore, there is no semantic mapping problem as far as I can see. If you want to map to HTML5/CSS, then simply map

It is preferable to match CSS/HTML all others things being equal, especially since TTML2 goes to a great length to provide a one-to-one mapping to CSS/HTML for ruby.

[skynavga]

According to the current ED of CSS Ruby Layout Module 1 [1], a ruby annotation container includes only rtc, but does not include ruby (from HTML5 element types).

The HTML specification implies that ruby is a container since it contains rt elements.

That may be true, but you cited the CSS Ruby Layout Module 1, which says that ruby-position applies to ruby annotation containers and not ruby containers. The former corresponds to our textContainer and the latter to our container.

However, how to specify position when there is no explicit ruby text container? The CSS module doesn't appear to support that usage;

This is done by specifying ruby-position on ruby:

That may work on some browser, but it is not what CSS says.

You need to create he implied text annotation container, which, in addition to the text I cited, is also supported by the second note under 10.2.35, which describes the syntax that is lacking an annotation text container as syntactic sugar, i.e., a shortcut.

[palemieux]

that may be true, but you cited the CSS Ruby Layout Module 1, which says that ruby-position applies to
ruby annotation containers and not ruby containers. The former corresponds to our textContainer and
the latter to our container.

Yes. The CSS-ruby-1 editor indicated that ruby-position only applies to ruby annotation containers.

As a result, this means there is a divergence since TTML2 allows tts:rubyPosition to apply to tts:ruby="text".

[skynavga]

I'm afraid I must disagree. See the example I give above in #945 (comment). It only applies to tts:ruby="text" for the purpose of mapping it to the implied ruby text container.

[palemieux]

It only applies to tts:ruby="text" for the purpose of mapping it to the implied ruby text container.

The anonymous ruby text container is the parent, so cannot inherit from the specified style on tts:ruby="text".

Anonymous ruby text container should be treated like anonymous spans, and style resolution and ISD processing should apply to them similarly.

[skynavga]

That's why this processing requirement is documented under 10.2.35.1 Special Semantics of Ruby Annotations, and not documented under style inheritance rules.

[palemieux]

In the spirit of both following CSS and avoiding special inheritance semantics, I suggest considering limiting the application of tts:rubyPosition to tts:ruby="textContainer"

[skynavga]

I think it is not necessary to make this change for the following reasons:

• if the shorthand syntax is used, without an explicit ruby text container (tts:ruby="textContainer"), then it will not be possible to specify ruby position;
• at present, we have an adequately defined mechanism to support use of ruby position when nthe shorthand syntax is used;
• this mechanism does not use inheritance semantics; it merely specifies that the results of processing appear as if there were a ruby text container and as if the ruby position had been specified on that ruby text container (this is not using inheritance), merely defining special processing semantics;
• it is trivial to map both uses in TTML2, i.e., uses with ruby text container and uses without ruby text container, to HTML5 and CSS and obtain the desired results; there is no semantic mismatch here that cannot be easily accommodated;
• at least one and maybe a second and third implementation of TTML2 already supports the current syntax and semantics.

My conclusion is that the change removes useful functionality that is already implemented and tested, and that there are no barriers to mapping the existing specification to HTML5/CSS syntax/semantics.

[palemieux]

if the shorthand syntax is used, without an explicit ruby text container (tts:ruby="textContainer"), then it will not be possible to specify ruby position;

That does not sound right: by your own argument, tts:rubyPosition can be specified on tts:ruby="container" in absence of tts:ruby="textContainer".

at least one and maybe a second and third implementation of TTML2 already supports the current syntax and semantics.

I ran into this issue while writing tests for imscJS, which currently does not support tts:rubyPosition on tts:ruby="textContainer".

My conclusion is that the change removes useful functionality that is already implemented and tested,

As far as I can tell, there are no TTML2 tests that cover this scenario, and, as indicated below, this issue was encountered while creating tests for IMSC 1.1.

[skynavga]

if the shorthand syntax is used, without an explicit ruby text container (tts:ruby="textContainer"), then it will not be possible to specify ruby position;

That does not sound right: by your own argument, tts:rubyPosition can be specified on tts:ruby="container" in absence of tts:ruby="textContainer".

Except that won't cover the case where the shorthand syntax is used and there are two tts:ruby="text" spans each assigned a distinct position.

My conclusion is that the change removes useful functionality that is already implemented and tested,

As far as I can tell, there are no TTML2 tests that cover this scenario, and, as indicated below, this issue was encountered while creating tests for IMSC 1.1.

The TTML tests repository is not yet populated with presentation tests, for which verification is underway.

[palemieux]

Except that won't cover the case where the shorthand syntax is used and there are two tts:ruby="text" spans each assigned a distinct position.

This is syntactically forbidden: at most one tts:ruby="text" can appear within a tts:ruby="container".

[skynavga]

@palemieux Ah, right. Thanks for correcting. In that case, your suggestion is probably workable. Let's finalize at tomorrow's meeting.

[skynavga]

Having just reviewed the current specification text, I have once again convinced myself that there is no problem here and that the semantics of applying ruby position to a <span tts:ruby="text"/> is perfectly well defined. The pertinent language is as follows:

10.2.37

When this attribute is specified on a span element for which the computed value of tts:ruby is text, then the ruby position semantics of the associated style property apply collectively to the inline areas generated by its implied ruby text container and its own ruby text content.

and

10.2.35.1

When performing presentation processing, isolated ruby content, namely, ruby base content or ruby text content that is specified without a ruby base container or ruby text container, respectively, is processed in such a manner as to imply the presence of an anonymous ruby base container and (or) anonymous ruby text container as required. An implied ruby base container and (or) implied ruby text container is required in order to generate and apply implied or collective styling semantics to an inline block area which contains the inline areas generated by the isolated ruby content.

Since the suggested change entails a substantive change with questionable utility, I do not support making this change at present. Perhaps by TTML2 2e we can revisit this case to see whether the current text needs any further change.

[css-meeting-bot]

The Working Group just discussed Remove application of tts:rubyPosition to ruby annotation text. ttml2#945, and agreed to the following:

• SUMMARY: No consensus for a change now.

The full IRC log of that discussion

<nigel> Topic: Remove application of tts:rubyPosition to ruby annotation text. ttml2#945
<nigel> github: https://github.com//issues/945
<nigel> Pierre: This is simply achieving better alignment with CSS. CSS does not allow
<nigel> .. ruby-position on text, only on text-container. My suggestion is to follow the same route.
<nigel> Nigel: I see Glenn's comment from 2 days ago that Pierre's suggestion is probably workable.
<nigel> Glenn: I have a problem with this. It will require a substantive change to back out the
<nigel> .. language that defines in what way ruby position is applied to text content. I have to
<nigel> .. dispute what was just said by Pierre. It does not disallow specifying it on ruby text, it
<nigel> .. just doesn't say that it applies to it. If we don't allow the currently specified semantics
<nigel> .. to apply in the way that it is defined that means we have to substitute some other
<nigel> .. normative text that says the ruby position that would be inherited from the container
<nigel> .. (tts:ruby="container") also applies to the implied ruby text container that is constructed
<nigel> .. during the presentation processing. It's a substantive change. It is not necessary to make
<nigel> .. any change here because the mapping to HTML5 and CSS is trivial to accomodate this.
<nigel> Pierre: It is not.
<nigel> s/omo/ommo
<nigel> Glenn: All you have to do is create an explicit ruby text container.
<nigel> Pierre: If one already exists that doesn't work.
<nigel> Glenn: If one already exists then it is an error to put another one on.
<nigel> Pierre: Sure but that means you cannot always add a ruby position. I'm trying to avoid
<nigel> .. exceptions and make things more robust.
<nigel> .. A ruby text container is already created anonymously if not present, so this does not
<nigel> .. change anything.
<nigel> Glenn: What that means is we have to redefine the semantics to say that the inheritance
<nigel> .. explicitly applies to the ruby text container. I do not agree with this change at this point.
<nigel> .. I'm willing to look again in 2nd Ed.
<nigel> Pierre: I would accept putting this feature as at risk. Alignment with CSS is important.
<nigel> Glenn: I object.
<nigel> .. To putting it at risk - it is already implemented in two implementations.
<nigel> Pierre: Which we've seen no tests for. I'd rather not get there Glenn. What I'd rather say is
<nigel> .. that we should be aligned with CSS. Half of this section is dedicated to stating how
<nigel> .. it is aligned with HTML and CSS.
<atai> q+
<nigel> Glenn: We have never made syntactic alignment a requirement, always functional alignment.
<nigel> Pierre: It's confusing for people.
<nigel> ack at
<nigel> Andreas: I'm not really into this issue in itself and have not reviewed this ruby application
<nigel> .. but I would heavily support Pierre's approach to align with CSS as much as possible.
<nigel> .. From the last discussion we had at TPAC with the CSS WG we really would like to bring
<nigel> .. TTML closer to CSS functional of course but also syntactically if possible would be better.
<nigel> .. There are a lot of reasons why we are not aligned with CSS but that is all history now.
<nigel> .. The direction is that we are getting closer to CSS and after TTML2 with TTML3 I do not
<nigel> .. know how it will go on but possibly there could be a major change. So in general I support
<nigel> .. what Pierre said.
<nigel> Glenn: The last published CR of CSS ruby level 1 was in 2014. The current text that
<nigel> .. Pierre is using is an ED that has no status. There is no certainty about when we are going
<nigel> .. to see a CSS Ruby layout level 1 Rec. I don't think we can talk about alignment with CSS
<nigel> .. in any real way here. Also Pierre has pointed out a number of times that the only
<nigel> .. implementation is in Firefox anyway so one wonders if, even if they solidified the spec now
<nigel> .. could they achieve closure without any other implementations. The risk is high and there
<atai> q+
<nigel> .. are a number of unresolved issues in CSS.
<nigel> Pierre: We should take the conservative approach.
<cyril> q+
<nigel> Glenn: IRT (Stefan) reviewed the current language and did not point out any misalignment.
<nigel> Pierre: This came from implementation work.
<nigel> ack at
<nigel> Andreas: The message from CSS was to come if there is a requirement not in CSS. If there
<nigel> .. is a possibility to step back and say we have a requirement not in CSS right now then
<nigel> .. we should take it there first and see how it gets on.
<nigel> Glenn: Good suggestion.
<nigel> Cyril: If you want TTML2 published in 2025 you should do that. We should favour stability
<nigel> .. at this point, in CR3. Alignment with CSS is fine but should not jeopardise TTML2 publication.
<nigel> .. In this case it does not look like a bug in the spec, but a problem of alignment to an ED
<nigel> .. that is not stable.
<nigel> Pierre: You're trading risk of implementation for risk of stability.
<nigel> ack cyril
<nigel> Cyril: It is exactly how the process works, to trade spec risk for implementation risk. Why
<nigel> .. don't we follow the process?
<nigel> Pierre: At this point imsc.js does not implement it correctly because of the spec.
<nigel> Cyril: It is not impossible to fix though. It is too late to fix now. We have to publish, we have to get it done.
<nigel> Pierre: You don't want to remove one word on the spec?
<nigel> Cyril: yes, now is too late. When it is it going to end?
<nigel> Glenn: I don't care what Pierre says about implementations. There are at least two implementations
<pal> q+
<nigel> .. with tests already even if they are not visible. This change requires at least two implementations
<nigel> .. to be changed, so I don't go with that. This issue is out of scope of the CfC review.
<nigel> .. Substantive changes out of scope here cannot pass muster.
<nigel> ack p
<nigel> Pierre: If we take this really seriously, no more changes, then we should make no more
<nigel> .. changes and move on. The time it will take to review all the other changes, which are
<nigel> .. editorial only in name because they affect substantive statements, is outweighed by
<nigel> .. the time it takes to fix this. We make a change if it is worth it.
<nigel> Glenn: We do not have consensus on whether it is worth it.
<nigel> Nigel: That is a key point.
<nigel> .. Pierre, is this something that you can live with, to make no change, given that a path
<nigel> .. has been laid out for how to implement in HTML and CSS, even if it is not the optimum for you?
<nigel> Pierre: I will have to check with my sponsors on that.
<nigel> Nigel: Okay.
<nigel> SUMMARY: No consensus for a change now.

[palemieux]

When performing presentation processing, isolated ruby content, namely, ruby base content or ruby text content that is specified without a ruby base container or ruby text container, respectively, is processed in such a manner as to imply the presence of an anonymous ruby base container and (or) anonymous ruby text container as required.

What does "as required" mean? Is the anonymous ruby base container needed for anything other than applying tts:rubyPosition, i.e. does it inherit any other styles from the ruby text?

[skynavga]

Per commenter's input at [1], deferring this issue as non-fatal; therefore, marking as ttml.next and closing. May be reopened for TTML2 2e processing.

[1] https://lists.w3.org/Archives/Public/public-tt/2018Aug/0055.html

[skynavga]

Removing ttml.next, leaving here for ttml2 2e processing.

[nigelmegitt]

Adding to agenda for this week's call - not sure if we need to re-open this to address it.

[skynavga]

Having just done a quick re-review of this issue, my position is that the currently documented CSS Ruby Layout Module Level 1 [1] is a very long way from forming a normative model that can (1) be understood, and (2) places the current TTML2 semantics in opposition to its stated (and understood) semantics.

To start with, I would note that [1] defines a ruby annotation container [box] to be an internal ruby box generated by an element which computed display property is ruby-text-container which is distinct from a ruby annotation [box] which is also an internal ruby box generated by an element which computed display property is ruby-text. As such, this doesn't appear to cover the case of ruby annotation [boxes] for which there is no ancestor ruby annotation container [box], but perhaps the section Anonymous Ruby Box Generation would shed some light on this matter.

[1] https://drafts.csswg.org/css-ruby-1/

[css-meeting-bot]

The Timed Text Working Group just discussed Remove application of tts:rubyPosition to ruby annotation text. ttml2#945, and agreed to the following:

• SUMMARY: Needs closer discussion with CSS experts to work out what needs to be done, to schedule for TPAC.

The full IRC log of that discussion

<nigel> Topic: Remove application of tts:rubyPosition to ruby annotation text. ttml2#945
<nigel> github: https://github.com//issues/945
<nigel> Glenn: I posted a comment recently. I tried to do a quick 30 minute review and it's somewhat complicated.
<nigel> .. There's a premise that somehow we're doing something different than CSS is.
<nigel> .. That was the point of departure for Pierre to file this originally I think.
<nigel> .. 1. I don't think the documented CSS model which I linked to in my comments in the issue is very mature yet.
<nigel> .. It has a lot of conceptual and semantic issues. It's quite difficult to understand and in order to really get a handle
<nigel> .. on what Pierre is trying to say, one has to have a deep understanding of that document and what it is trying to say.
<nigel> .. So I'm not sure that there is a problem here at this point and it may be that if either myself or Pierre can get up to speed
<nigel> .. on the details of this issue we might we able to have a sidebar with Koji or Elika at TPAC to try to hash it out but
<nigel> .. I know I personally have to get it back in my head and review the current CSS WD.
<nigel> .. I don't think we can take any more action on it at this point.
<nigel> .. 2. I don't have any test content from Pierre that would show there is something broken here which I would like to see
<nigel> .. before I understand that there's a problem or not.
<nigel> .. He does refer to a codepen in some early comments so I need to go back and look at that because this came up
<nigel> .. when he was doing some ruby implementation work in imsc.js. Without doing that I cannot give more detail.
<nigel> q?
<nigel> .. The basic top level question he was asking is if we need ruby position to apply to the top level ruby containers as well
<nigel> .. as the ruby text containers and my original response to that was that we need it to apply to the top level ruby
<nigel> .. container in the case that the author did not use the ruby text container but used ruby text as children directly of the
<nigel> .. top level ruby container. That was the original motivation for saying that it applies.
<nigel> Pierre: [arrives]
<nigel> Nigel: Proposal is to discuss this at TPAC, either in our meeting, our joint CSS WG meeting or in a separate session less formally.
<nigel> Pierre: Sounds good to me.
<nigel> SUMMARY: Needs closer discussion with CSS experts to work out what needs to be done, to schedule for TPAC.

[skynavga]

Added to TPAC Agenda, https://www.w3.org/wiki/TimedText/tpac2019#Topics.

[css-meeting-bot]

The Timed Text Working Group just discussed Remove application of tts:rubyPosition to ruby annotation text. ttml2#945, and agreed to the following:

• SUMMARY: Issue not time critical for us, work alongside CSS and i18n to get an aligned solution across TTML and CSS.

The full IRC log of that discussion

<nigel> Topic: Remove application of tts:rubyPosition to ruby annotation text. ttml2#945
<nigel> github: https://github.com//issues/945
<cyril> glenn: the request here is to remove application of ruby position from ruby annotation text
<cyril> ... but to leave it for ruby container text
<cyril> ... right now TTML2 says it applies to ruby container and text
<cyril> ... CSS is not very clear
<cyril> ... the original reason was because you can have text without a text ocntainer
<nigel> -> https://www.w3.org/TR/2014/WD-css-ruby-1-20140805/#propdef-ruby-position CSS ruby-position
<cyril> ... in that case you want to be able to specify position
<nigel> -> https://www.w3.org/TR/ttml2/#style-attribute-rubyPosition TTML2 tts:rubyPosition
<cyril> ... but you can only have one text annotation present if you don't have a text container
<cyril> ... so you cannot have one that says before and one that says after
<cyril> nigel: in terms of delta with CSS, CSS says applies to ruby annotation containers
<cyril> glenn: but a container says applicable to boxes not elements
<cyril> ... "ruby annotation containers are internal ruby boxes"
<cyril> ... there is some ambiguity in the language
<cyril> cyril: CSS spec is still in WD
<cyril> glenn: 5 year discrepancies between WD and ED
<cyril> ... the status of CSS specs in this area are not very firm
<cyril> glenn: what problem are we solving by removing it
<cyril> pal: let's match CSS
<cyril> glenn: but CSS has not updated the WD since t5 years
<cyril> pal: also there is no reason to let it apply to text
<cyril> glenn: but a text can have a text without text container
<cyril> pal: there is an implied one
<cyril> glenn: but there is no way to refer to it
<cyril> glenn: we could just refer to the definition of ruby test container
<cyril> ... in section 10.2.21.1
<cyril> pal: ruby position is inherited
<cyril> ... you never need to specify on ruby text
<cyril> ... because you can always specify on the container
<cyril> ... and it is inherited on the ruby text container
<atai> q+
<cyril> ack
<cyril> atai: from what I understand, the difference between CSS and TTML is that the ruby position can be specified on a different structural element?
<cyril> pal: no, it's only application
<gkatsev> q?
<gkatsev> ack atai
<cyril> ... CSS says it does not apply on text, just text container
<cyril> pal: removing it from text does not remove any functionality
<cyril> glenn: that's wrong, because you can specify it on a span ruby=text and it has the semantics of applying to that annotation text or the container that's implied that contains it
<cyril> ... if you removing it, it would not have any effect
<cyril> nigel: is it true that in order to get the same functionality if you don't allow on text, you'd have to create an explicit text container?
<cyril> pal: you can specify it on the ruby element, and it will inherit to the implied ruby text container
<cyril> glenn: that doesn't deal with content already fielded that is putting ruby position on ruby annotation text elements
<cyril> pal: in the order of priority, it is not the most important feature
<cyril> glenn: do you agree that if we remove the ability, we are breaking content?
<cyril> ... it does make a technical change
<cyril> atai: we do not need a resolution today
<cyril> ... but we should agree to align with CSS whenever possible
<cyril> cyril: it's difficult to align with something not stable
<cyril> nigel: should we tell CSS to do the way we do it?
<cyril> glenn: yes
<cyril> atsushi_: i18n and CSS is working on updating the CSS spec
<cyril> ... to finalize the element structure
<cyril> glenn: it's not the structure in this case, but on the property
<cyril> nigel: if this work changes the element structure this would have an effect
<cyril> glenn: I doubt it would change the element structure, just the style definition
<cyril> nigel: does that mean we have a place to contribute this idea?
<cyril> atsushi_: current HTML does not have rtc
<cyril> ... that may be why there is a difference
<cyril> nigel: if they did not have a rtc, how do they apply ruby position
<cyril> atsushi_: they do it on rt
<cyril> nigel: we should get alignment with CSS by having them apply it to rtc
<nigel> s/rtc/rt
<cyril> nigel: anybody wants to take the action?
<cyril> atai: do you want to wait until the i18n work is finalized?
<cyril> atsushi_: yes
<cyril> atai: makes sense to me
<cyril> glenn: I will file an issue with the CSS WG
<cyril> atsushi_: we want to intrduce rtc and tabular ruby
<cyril> ... if we do that, it might be easier for every one
<cyril> atai: as a group, we should align
<cyril> cyril: we should make sure TTWG, CSS and I18N are all discussing the same thing
<nigel> -> https://github.com/w3c/ttwg/issues/69 Action on Glenn
<nigel> SUMMARY: Issue not time critical for us, work alongside CSS and i18n to get an aligned solution across TTML and CSS.
<cyril> example of Cap2TT output: https://raw.githubusercontent.com/skynav/ttt/master/ttt-cap2tt/src/test/resources/com/skynav/cap2tt/app/imsc11/test-015-ruby-position.expected.xml