Open palemieux opened 6 years ago
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.
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.
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.
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"
.
I'm afraid I must disagree. See the example I give above in https://github.com/w3c/ttml2/issues/945#issuecomment-409001643. It only applies to tts:ruby="text"
for the purpose of mapping it to the implied ruby text container.
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.
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.
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"
I think it is not necessary to make this change for the following reasons:
tts:ruby="textContainer"
), then it will not be possible to specify ruby position;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.
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.
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 ontts:ruby="container"
in absence oftts: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.
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".
@palemieux Ah, right. Thanks for correcting. In that case, your suggestion is probably workable. Let's finalize at tomorrow's meeting.
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 oftts:ruby
istext
, 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.
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.
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?
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
Removing ttml.next, leaving here for ttml2 2e processing.
Adding to agenda for this week's call - not sure if we need to re-open this to address it.
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.
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.
Added to TPAC Agenda, https://www.w3.org/wiki/TimedText/tpac2019#Topics.
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.
TTML2 currently specifies that
tts:rubyPosition
applies totextContainer
ortext
CSS
ruby-position
applies to ruby annotations containers, i.e.ruby
andrtc
.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 becontainer
ortextContainer
.becomes
but the following remain unchanged:
See also #832