Bug 19207 - i18n-ISSUE-194: Multiple sequential rt elements
Summary: i18n-ISSUE-194: Multiple sequential rt elements
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Robin Berjon
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2012-10-02 13:58 UTC by i18n IG
Modified: 2014-03-06 23:17 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description i18n IG 2012-10-02 13:58:41 UTC
http://dev.w3.org/html5/spec/the-ruby-element.html#the-ruby-element (4.6.20 The ruby element) says that base text can be followed by "One or more rt elements", which I assume refers to the fact that you can do something like

<ruby>BASE<rt>annotation 1<rt>annotation 2</ruby>

and expect that both annotations will be associated with the same base text.

In http://dev.w3.org/html5/spec/the-rt-element.html (4.6.21 The rt element) however, it says that

"An rt element that is a child of a ruby element represents an annotation (given by its children) for the *zero* or more nodes of phrasing content *that immediately precedes it* in the ruby element, ignoring rp elements." (my emphasis)

This seems to imply that the second rt element contains an annotation for an 'empty' base text - ie. the annotation sits on the baseline after any preceding base text. This is what Chrome currently does, but not what IE does - see http://www.w3.org/International/tests/html-css/ruby/results-ruby-markup#multiply

These two descriptions seem to be contradicting each other. Please resolve that.

(i18n WG endorsed)
Comment 1 Erika Doyle Navara 2013-01-02 22:36:21 UTC
I walked the following markup through the ruby algorithm:

<ruby>BASE<rt>annotation 1<rt>annotation 2</ruby>

. . . and the algorithm seems to imply that the 2nd annotation be associated with the "BASE" text, rather than an empty text node. Here is a summary of the walkthrough:

1) Follow steps 1 through 16 (nothing really happens yet except initializing variables). 
     index == 1

2) Step 17 sends us back to "base mode" (step 13), but this time index-th node is a <rt> element, for which we run "set the current base text" and then jump to "annotation mode" (step 18).
   index == 1
   current base text is "BASE"

3) Annotation mode (step 18) then will "push a ruby annotation", where "annotation 1" is associated with current base text ("BASE"). We then jump to "annotation mode increment" (step 21). At end of step 21:
 index == 1
 current base text is "BASE"
 lookahead index == 2

4) Continuing on, step 23 has us set index equal to lookahead index because the next node is another <rt> element. We then enter "annotation mode" again (step  18).
  index == 2
  current base text is "BASE"
  lookahead index == 2

5) Step 18 has us "push a ruby annotation" again, where we associate the annotation range "annotation 2" with current base text, which has not changed from "BASE".

Unless there is a flaw in my logic, I propose we change the description for rt element to conform to the implications of the algorithm (rather than the other way around), as this option requires the least amount of change to the spec. 

Here is the proposed change (staged for review):


It changes this part of the spec:

Comment 2 Silvia Pfeiffer 2013-01-07 06:25:50 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If
you are satisfied with this response, please change the state of
this bug to CLOSED. If you have additional information and would
like the Editor to reconsider, please reopen this bug. If you would
like to escalate the issue to the full HTML Working Group, please
add the TrackerRequest keyword to this bug, and suggest title and
text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this
document:   http://dev.w3.org/html5/decision-policy/decision-policy-v2.html

Status: Accepted
Change Description: https://github.com/w3c/html/commit/01d05d4a98d47d8eb7db33efc7473750302726de
Rationale: adopted WHATWG fix - I believe Ian took inspiration from Erika's analysis, so: thanks!
Comment 3 Erika Doyle Navara 2013-01-07 19:17:34 UTC
(In reply to comment #2)
> Rationale: adopted WHATWG fix - I believe Ian took inspiration from Erika's
> analysis, so: thanks!

Wish I could take credit, but looks like he made the change a couple days before I posted my comment here :)

In any case, Robin will be working with the i18n IG on all ruby matters going forward.
Comment 4 Addison Phillips 2014-03-06 23:17:44 UTC
I18N is satisfied by these changes. Thank you.