This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10830 - i18n comment : Please add support for rb
Summary: i18n comment : Please add support for rb
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: TrackerIssue
Depends on:
Blocks:
 
Reported: 2010-09-29 13:39 UTC by i18n CJK group
Modified: 2012-01-05 14:36 UTC (History)
19 users (show)

See Also:


Attachments

Description i18n CJK group 2010-09-29 13:39:43 UTC
Comment from the i18n review of:
http://dev.w3.org/html5/spec/

Comment 7
At http://www.w3.org/International/reviews/0802-html5/
Editorial/substantive: E
Tracked by: RI

Location in reviewed document:
4.6.18 The ruby element [http://www.w3.org/TR/2010/WD-html5-20100624/text-level-semantics.html#the-ruby-element]

Comment:In all the web sites that we looked at that currently use ruby markup in the wild, over 90% of code uses the rb tag. The current HTML5 model for ruby simplifies the code generally, but making the rb element obsolete will make most existing ruby code non-conformant and make it more difficult to copy code that follows the Ruby Annotation model, from XML or other formats, into HTML5.

Please allow optional use of the rb element as part of the HTML5 model.
Comment 1 Ian 'Hixie' Hickson 2010-09-30 09:08:13 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.html

Status: Rejected
Change Description: no spec change
Rationale: IE doesn't support <rb> (it ignores it) and in practice many pages don't actually use it (the HTML definition of ruby was based on extensive research for real use of ruby markup in the wild). While there is a short-term cost to dropping the <rb> element from the content model, there is a long-term win since the element is essentially useless in practice.
Comment 2 fantasai 2010-09-30 09:35:02 UTC
In addition to the markup compatibility concerns raised above, there's another one: that having an <rb> element allows styling of the ruby base text independently of the ruby text. This is needed for example to control line breaking: depending on type of ruby contents and on the styling of the document, line breaking may or may not be allowed at otherwise-valid breakpoints in the ruby base text.

I agree that in the general case, the markup is much simpler if ruby bases are implied by the <rt> markup. However, in some cases it is necessary to have a more concrete element to address.
Comment 3 Simon Pieters 2010-09-30 12:12:58 UTC
You could use <span> for styling purposes. However I agree that <rb> would be simpler to use compared to <span> (especially if the parser auto-closes <rb>).
Comment 4 Simon Pieters 2010-09-30 12:14:34 UTC
(Also, &nbsp; can be used for the "no line-breaks allowed" use case.)
Comment 5 Ian 'Hixie' Hickson 2010-09-30 18:33:15 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.html

Status: Rejected
Change Description: no spec change
Rationale: 

You can almost always just style the <ruby>. In practice, it's rare that you'd want to style the ruby base differently, since the whole point is that the ruby base looks like the rest of the content.

In any case, that's a styling issue. If it's really a problem, we could always address this with a pseudo-element. We should probably do that anyway (have a pseudo-element that can style certain spans of descendants); it's the flip side of ::outside.
Comment 6 Koji Ishii 2010-12-29 04:00:04 UTC
I'm not used to using W3C Bug Tracking service, I'm sorry in advance if this is inappropriate way to respond to an issue. I also apologize for the late comment.

I was reviewing HTML5 ruby for accessibility purposes, and I found that without rb tag, accessibility readers cannot distinguish base characters to highlight when multiple rt exist through DOM.

<ruby>
  B1<rt>R1</rt>
  B2<rt>R2</rt>
</ruby>

When reader is reading "R1", I can't get "B1" through DOM as far as I understand. Apps want to distinguish which rt corresponds to which base characters, and I suppose rb tag is the one that gives me.

Could you please reconsider the decision?
Comment 7 Koji Ishii 2010-12-29 04:07:34 UTC
I also would like to note that all DAISY books in Japan today use rb tags, and I suppose the reseearch did not cover DAISY, did it? HTML5 not supporting rb means that they have to convert all existing source files, and modify reader applications not to rely on rb tags. The former is annoying, and the later I'm not sure if it's technical feasible.
Comment 8 Koji Ishii 2010-12-31 17:22:42 UTC
Sorry for multiple comments in a row, but I was reading Yomiuri Online, the only news site that use ruby within major Japanese newspaper sites. I found they use rb tag.

I then went to Google, typed "ruby" in Japanese, and looked into first 5 or 6 sites. All sites I saw there use rb tag too.

From what you said, I thought very few sites are using rb tag, but this quick and rough investigation resluted in opposite.

This leads me to a question; would you mind if I ask what the scope of the research you mentioned was, and what the result was? How many pages/sites/authoring tools have rb tag today in your estimates, and how much the "short-term cost" is?

If majorities are using rb tag, I don't understand the value of deprecating rb tag in HTML5. Rather, it could bring confusions.
Comment 9 fantasai 2011-01-12 21:49:47 UTC
So I've heard several problems so far with the lack of the <rb> tag currently, and also in talking with a number of people about the appropriate styling of ruby text. Here's the summary:

1. Compat: Markup compatibility with existing documents that use <rb>.

2. Styling: More straightforward styling of the base text.

3. Accessibility: Can easily identify and hide base text, replacing it
   with the ruby text for children and others who have trouble with kanji.
   rb { display: none; } rt { display: inline; }

4. Fallback: Current HTML5 markup does not allow appropriate fallback for
   multi-syllable ruby (example below).

The example for fallback is the following: Tokyo is written with two kanji characters, &#26481;, which is pronounced &#12392;&#12358;, and &#20140;, which is pronounced &#12365;&#12423;&#12358;. Each base character should be annotated individually.

     _   _      _  _  _
    |_| |_|    |_||_||_|  
  +---------+ +---------+
  |         | |         |
  |         | |         |
  |         | |         |
  |         | |         |
  +---------+ +---------+

However the fallback should be &#26481;&#20140;(&#12392;&#12358;&#12365;&#12423;&#12358;) not &#26481;(&#12392;&#12358;)&#20140;(&#12365;&#12423;&#12358;). This could be achieved if the ruby could be written as
  <ruby>
    <rb>&#26481;</rb><rb>&#20140;</rb>
    <rt>&#12392;&#12358;</rt><rt>&#12365;&#12423;&#12358;</rt>
  </ruby>

(The behavior here would be the same as for DT+DD+ sets inside a DL.)

5. Advanced ruby layouts: In addition to fallback, this would allow the markup to express both the correspondance between rb rt pairs and the grouping of rt and rb sets, which can then be exploited by the styling system to handle the various styling requirements of such ruby. (Specifically, ruby sets like this can be styled with the ruby text apart or grouped together--this is a stylistic choice, not a markup one--but even if grouped together breaking the line must keep corresponding <rt> and <rb> pairs together.)

The last two require extending the way ruby behaves in HTML5, which probably would be a separate bug, but they also require the <rb> tag to exist, which is the issue here.
Comment 10 Sam Ruby 2011-01-17 21:54:33 UTC
Reminder: - Jan 22, 2010 is the cutoff for escalating bugs for pre-LC consideration - all issues in tracker, calls for proposal issued by this date.
Consequences of missing this date: any further escalations will be treated as a Last Call comment.
Comment 11 Ian 'Hixie' Hickson 2011-02-15 01:35:50 UTC
Note that IE *does not parse* the <rb> element. It treats it like a void element. It completely ignores the tag for ruby processing as far as I can tell. <rb> has no effect on IE.

(In reply to comment #6)
> 
> I was reviewing HTML5 ruby for accessibility purposes, and I found that without
> rb tag, accessibility readers cannot distinguish base characters to highlight
> when multiple rt exist through DOM.
> 
> <ruby>
>   B1<rt>R1</rt>
>   B2<rt>R2</rt>
> </ruby>
> 
> When reader is reading "R1", I can't get "B1" through DOM as far as I
> understand.

Why not?

> Apps want to distinguish which rt corresponds to which base
> characters, and I suppose rb tag is the one that gives me.

The semantic is simple: it's the previous siblings of the <rt> up to the previous <rt> or the start of the <ruby>.


(In reply to comment #7)
> I also would like to note that all DAISY books in Japan today use rb tags, and
> I suppose the reseearch did not cover DAISY, did it?

No, the target here is the Web. If the current spec is incompatible with DAISY implementations and content, then that content is also incompatible with IE and those implementations are also incompatible with legacy Web content.


(In reply to comment #8)
> 
> This leads me to a question; would you mind if I ask what the scope of the
> research you mentioned was, and what the result was?

I do not recall exact numbers. The study was based on parsing the Google search index.


> How many
> pages/sites/authoring tools have rb tag today in your estimates, and how much
> the "short-term cost" is?

The cost is nil. The element is ignored in browsers and in the spec, and does not affect the semantics of the page. It is equivalent to <span> per the spec.


> If majorities are using rb tag, I don't understand the value of deprecating rb
> tag in HTML5. Rather, it could bring confusions.

The value is that the element is unnecessary and not having it is simpler.


(In reply to comment #9)
> 
> 2. Styling: More straightforward styling of the base text.

Just style the ruby element.


> 3. Accessibility: Can easily identify and hide base text, replacing it
>    with the ruby text for children and others who have trouble with kanji.
>    rb { display: none; } rt { display: inline; }

This would be trivial given extensions to CSS to handle the many cases like this (e.g. styling runs of <dt>s or <dd>s).


> 4. Fallback
> 5. Advanced ruby layouts

These are both feature requests beyond what IE implements and thus should be filed as separate bugs to be handled in a future version. (We can always _add_ <rb> later if it's really necessary for these cases.)


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.html

Status: Rejected
Change Description: no spec change
Rationale: The <rb> element is unnecessary and not implemented in IE, which is what we are currently trying to specify.
Comment 12 Koji Ishii 2011-02-17 03:38:25 UTC
Ian,

I understand you guys must have spent huge efforts on this issue including the help from Google to make the decision and do not want to revisit, but I'd like to ask you to reconsider the decision if the facts you made the decision based on have changed or being questioned.

> No, the target here is the Web. If the current spec is incompatible 
> with DAISY implementations and content, then that content is also 
> incompatible with IE and those implementations are also incompatible 
> with legacy Web content.

IE9 standard mode parses rb tag and build DOM tree correctly[1]. It accepts "rb { font-size:24pt; }" and it does style ruby base text as expected. So IE9, Safari, Chrome, and Firefox, they all accepts rb tag in an interoperable way, and therefore we don't have any reasons to remove it from that perspective. Forbidding rb element only makes existing documents incompatible with HTML5.

> I do not recall exact numbers. The study was based on parsing the 
> Google search index.

We have different results from other studies (i18n says over 90% uses rb tag, which matches to my wild investigation and to discussions in W3C Japanese ML.) Shouldn't we dig into why the studies get so different results, and shouldn't we re-evaluate the conclusion if the base study was in question?

> The semantic is simple: it's the previous siblings of the <rt> up to 
> the previous <rt> or the start of the <ruby>.

Are you saying we should add this special selector just for Ruby? It reduces one element from HTML5, and add one special selector to CSS3. I can't see how it helps the web. Isn't the total cost to do so higher than allowing rb element? It looks to me that rb element is simpler if "the web" includes both HTML and CSS.

> The value is that the element is unnecessary and not having it is simpler.

Can I ask to whom it is unnecessary? The semantics for "ruby base text" is clear and necessary. That's the consensus in Japanese ML, and I've never heard of any Japanese saying the semantics is unnecessary.

It's true that some Japanese want even simpler markup like just an attribute for special cases, but nobody wanted to forbid rb element.
 
> Just style the ruby element.

Doing so affects ruby text as well. What fantasai said is to style ruby base text separately from ruby text, and that's not feasible without adding special selector, and that adds more total costs to the web as said above.

> This would be trivial given extensions to CSS to handle the many cases 
> like this (e.g. styling runs of <dt>s or <dd>s).

There's no *trivial* extensions than allowing rb element, which has been already implemented in an interoperable way. It has to be spec'ed, implemented, tested, and authors must learn the new way. 

[1] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cruby%3E%3Crb%3Ebase%3C/rb%3E%3Crt%3Etext%3C/rt%3E%3C/ruby%3E
Comment 13 Addison Phillips 2011-03-30 15:52:31 UTC
Per our most recent teleconference [1], the I18N WG has asked me [2] to indicate our support for reopening this bug and asks the editor to reconsider it.

We understand that IE9 and WebKit both support the <rb> tag, that at least some web sites use it, and that it has some value serving as a basis for styling the ruby base.

Note to chairs: our WG is okay with this bug being treated as a post-LC item.

[1] http://www.w3.org/2011/03/30-i18n-minutes.html
[2] http://www.w3.org/International/track/actions/35 I18N-ACTION-35
Comment 14 Michael[tm] Smith 2011-08-04 05:06:27 UTC
mass-moved component to LC1
Comment 15 Ian 'Hixie' Hickson 2011-08-06 03:33:49 UTC

*** This bug has been marked as a duplicate of bug 13113 ***
Comment 16 Murata 2011-08-07 00:28:41 UTC
I strongly believe that this is not a duplicate of bug 13113.
Very many people think that rb be added to HTML5, and rb has 
been extensively used.  Meanwhile, few think that rbc and 
rtc be added.

Marking this bug as a duplicate of 13113 will throw the baby 
out with the bath water.
Comment 17 Martin Dürst 2011-08-08 04:12:33 UTC
(In reply to comment #16)

> Very many people think that rb be added to HTML5, and rb has 
> been extensively used.

Richard also reported that rb is widely used. But it would be good to have pointerts to sites or other kinds of statistics that support this.
Comment 18 Koji Ishii 2011-08-08 04:27:49 UTC
> Richard also reported that rb is widely used. But it would be good to have
> pointerts to sites or other kinds of statistics that support this.

Yomiuri newspaper site:
http://www.yomiuri.co.jp/national/news/20110808-OYT1T00316.htm

Automatic ruby program
http://mt.adaptive-techs.com/httpadaptor/servlet/HttpAdaptor?.h0.=fp&.ui.=trial&.up.=&.ro.=kh&.st.=rb

How many examples do you think is necessary? As far as I looked around quickly, all sites except those claim to be HTML5 compliant use rb tag.
Comment 19 Ian 'Hixie' Hickson 2011-08-08 21:46:13 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.html

Status: Rejected
Change Description: no spec change
Rationale: 

If this is just asking for <rb>, not for the feature that makes <rb> useful, then this is definitely a WONTFIX. Legacy IE browsers ignored <rb> in practice. In the model supported by the spec, the element provides no useful purpose.
Comment 20 Murata 2011-08-09 00:27:32 UTC
Re: Legacy IE browsers ignored <rb> in practice.

It appears that the editor did not even bother to read comments.
Ishii-san already wrote:

  IE9 standard mode parses rb 
  tag and build DOM tree correctly[1]. It accepts "rb
  { font-size:24pt; }" and it does style ruby base text as expected. So IE9,
  Safari, Chrome, and Firefox, they all accepts rb tag in an interoperable way,
  and therefore we don't have any reasons to remove it from that perspective.
  Forbidding rb element only makes existing documents incompatible with HTML5.

 ...

[1]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cruby%3E%3Crb%3Ebase%3C/rb%3E%3Crt%3Etext%3C/rt%3E%3C/ruby%3E
Comment 21 Murata 2011-08-09 16:18:16 UTC
I request that this issue be escalated to the HTML working group, since 
I am "dissatisfied with the resolution" and I do "not believe it is productive 
to ask the editor to reconsider".

The editor appears to ignore two important facts.  First, rb is widely used 
by existing web pages (e.g., Yomiuri).  Second, some existing implementations 
(e.g., IE) already create a DOM node for rb elements and apply styles for rb.
Comment 22 Ms2ger 2011-08-09 16:25:00 UTC
You have already asked the editor to reconsider. You can't both do that *and* request to open a tracker issue. Please read the link that was provided.
Comment 23 Addison Phillips 2011-08-09 16:38:30 UTC
(In reply to comment #22)
> You have already asked the editor to reconsider. You can't both do that *and*
> request to open a tracker issue. Please read the link that was provided.

Please note: The I18N WG has not yet considered the editor's response.
Comment 24 Murata 2011-08-09 17:44:52 UTC
I am sorry that I mistakenly changed the status to "REOPENDED".  I 
did not realize that the change is a request for reconsideration 
by the editor.

I now changed the status back to "RESOLVED" and "WONTFIX", and 
also specified the keyword "TrackerRequest".
Comment 25 I18n Core WG 2011-08-17 14:52:11 UTC
(In reply to comment #17)

> Richard also reported that rb is widely used. But it would be good to have
> pointerts to sites or other kinds of statistics that support this.

Koji added some pointers.  Here are a few more.

http://lists.w3.org/Archives/Public/www-international/2010JanMar/0151.html

http://lists.w3.org/Archives/Public/www-international/2010JanMar/0114.html

http://lists.w3.org/Archives/Public/www-international/2010JanMar/0115.html (includes a link to a ruby generator that you can run any page through)
Comment 26 Addison Phillips 2011-08-17 16:06:20 UTC
This is a response on behalf of the I18N WG. In Comment 19, the editor rejected this change, citing the need for a feature that makes <rb> useful. The CJK community and our own observation suggest that the <rb> tag is widely used by content and widely supported by current and legacy browsers. We therefore feel that it is contrary to general interoperability and backwards compatibility to not include it in HTML5 as requested.

Non-IE browsers support the <rb> tag, including Firefox, Safari (WebKit), Chrome, Opera, etc. In addition, IE9 provides support for the tag. Older IE implementations did, indeed, not implement <rb>, but are not impaired by its presence. 

One important "feature" the <rb> element provides is the ability to style ruby base text as distinct from the matching ruby text.

We agree that <rb> is not always necessary in order to implement basic ruby markup in HTML5 documents and that it should be an *optional* element. However, there is general consensus on the part of the Japanese community that it is desirable to preserve this element. We would therefore like to request that you restore the <rb> element as optional markup identifying the ruby base text inside a <ruby> tag sequence.
Comment 27 Ian 'Hixie' Hickson 2011-08-17 17:53:26 UTC
Do you have any links to pages that actually style the <rb> element? I looked through some of those cited above, and couldn't find any where the <rb> element wasn't just a waste of the author's time.

Note that despite repeated claims to the contrary, none of the browsers actually support <rb> any differently than any other random element like <foo>. (For example, try <ruby><rb>base<rt>annotation</ruby> in the live DOM viewer. Notice how the <rb> element does not close the <rt> element.)

Is there any reason that <span> doesn't already provide all of the power that authors need here?
Comment 28 Murata 2011-08-18 02:44:22 UTC
I do not understand why HTML5 has dt but does not have rt.  All arguments against rt apply to dt.  
Even if dt is not specified, modern browsers work.

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cdl%3Eafsaf%3Cdd%3Easfadfafassfd%3C/dd%3E%3C/dl%3E
Comment 29 Murata 2011-08-18 03:12:06 UTC
(In reply to comment #28)
> I do not understand why HTML5 has dt but does not have rt.  All arguments
> against rt apply to dt.  
> Even if dt is not specified, modern browsers work.
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cdl%3Eafsaf%3Cdd%3Easfadfafassfd%3C/dd%3E%3C/dl%3E

Oops, replace rt by rb.
Comment 30 Ms2ger 2011-08-18 07:54:39 UTC
(In reply to comment #28)
> I do not understand why HTML5 has dt but does not have rt.  All arguments
> against rt apply to dt.  
> Even if dt is not specified, modern browsers work.
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cdl%3Eafsaf%3Cdd%3Easfadfafassfd%3C/dd%3E%3C/dl%3E

Please look at <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1111>.
Comment 31 Murata 2011-08-18 10:20:20 UTC
> Please look at
> <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1111>.

This example is obviously broken, since rb is required to precede rt.  
Please try 

<ruby><rb>annotation<rt>base</ruby>

instead.
Comment 32 Ms2ger 2011-08-18 12:33:51 UTC
Completely broken code is a good description of 99% of the web. But sure, try <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1113>.
Comment 33 Murata 2011-08-22 01:19:59 UTC
> Completely broken code is a good description of 99% of the web. But sure, try..

I do not understand your argument.  Why can behaviour for 
broken code be a reason to drop rb?  

"HTML Working Group Decision Policy" document" has a para 
shown below:

  I strongly think that "If the commenter is dissatisfied with the 
  resolution and does not believe it is productive to ask the editor
  to reconsider, he or she may ask to escalate the issue to the issue tracker. "

I would like to request the WG to consider (1) dropping dt of 
dl, (2) introducing rb, and (3) providing convincing argument 
for keeping dt whild turning down rb in spite of repeated 
requests from I18N and Japan.
Comment 34 Ms2ger 2011-08-22 11:33:46 UTC
I don't care if it's in or out. You claimed "All arguments
against rt apply to dt."; the only point I wish to make is that this claim is factually incorrect.
Comment 35 Murata 2011-08-22 12:17:00 UTC
Again, I think that error recovery for broken 

  <ruby><rb>annotation<rt>base<rb>annotation<rt>base</ruby>

does not prove information useful for this discussion.  

In the case of dl, there can be several (dt, dd) pairs.
In the case of ruby, only one pair is allowed.  Thus, 
error recovery is different.  That's all.

I wrote: "All arguments against rt apply to dt.".  I have 
seen two arguments.  The argument that rb is not widely 
used is very incorrect.  The argument that span is 
always available certainly applies to dt.

I would like to ask this issue be discussed by the WG, 
which certainly has developers of existing browsers.
Comment 36 Maciej Stachowiak 2011-08-22 20:08:25 UTC
Putting this bug back in WONTFIX state since it has TrackerRequest, and a bug cannot be both reopened and tracker-requested. Also, this bug has been reopened many times already, so escalating to the tracker is probably a better path forward.
Comment 37 Ms2ger 2011-08-23 09:04:48 UTC
(In reply to comment #36)
> Putting this bug back in WONTFIX state since it has TrackerRequest, and a bug
> cannot be both reopened and tracker-requested. Also, this bug has been reopened
> many times already, so escalating to the tracker is probably a better path
> forward.

To WONTFIX, you said?
Comment 38 Addison Phillips 2011-08-23 14:52:39 UTC
(In reply to comment #36)
> Putting this bug back in WONTFIX state since it has TrackerRequest, and a bug
> cannot be both reopened and tracker-requested. Also, this bug has been reopened
> many times already, so escalating to the tracker is probably a better path
> forward.

Maciej,

The I18N WG did not ask for an escalation to tracker. If you would prefer to handle this bug that way, can you provide our WG with guidance on what the process and timing is? And can you please provide a pointer to the tracker item?

Addison
Comment 39 Sam Ruby 2011-08-26 19:13:40 UTC
From the EDITOR'S RESPONSE "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"

Does anybody want to propose title and text for the tracker issue?  Or to
create the tracker issue themselves?
Comment 40 Addison Phillips 2011-08-26 19:21:48 UTC
(In reply to comment #39)
> From the EDITOR'S RESPONSE "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"
> 
> Does anybody want to propose title and text for the tracker issue?  Or to
> create the tracker issue themselves?

Title: restore <rb> as an optional element

Text: In all the web sites that we looked at that currently use ruby markup
in the wild, over 90% of code uses the rb tag and most of the current browser versions support the tag. The current HTML5 model for ruby simplifies the code generally, but making the rb element obsolete will make most existing ruby code non-conformant and make it more difficult to copy code that follows the Ruby Annotation model, from XML or other formats, into HTML5. The editor has repeatedly denied requests for this element to be restored, although both CJK and I18N communities support its inclusion for backwards compatibility with existing Web content, existing browser implementations, and for occasional practicality in styling ruby base text. Although the HTML5 ruby model does not require its use and although we do not believe it should be required, we would like the <rb> element restored as an optional element within HTML5 ruby.

Please restore the <rb> tag as an optional element.
Comment 41 Sam Ruby 2011-08-26 19:31:57 UTC
Tracker issue opened: http://www.w3.org/html/wg/tracker/issues/172
Comment 42 Simon Pieters 2011-08-26 22:15:15 UTC
Data from 2008:

http://philip.html5.org/data/tag-count-total.txt

[[
Most common element names, counting total number of occurrences (out of 130K from dmoz.org), showing names with XML escaping:

91 rp
84 ruby
84 rt
41 rb
]]
Comment 43 Simon Pieters 2011-08-26 22:18:23 UTC
Same but counting pages instead of elements:

[[
Most common element names, counting number of pages (out of 130K from dmoz.org) they appear on, showing names with XML escaping:

14 rt
13 ruby
10 rp
10 rb
]]
Comment 44 Simon Pieters 2011-08-26 22:19:16 UTC
(In reply to comment #43)
> Same but counting pages instead of elements:

Forgot the link. http://philip.html5.org/data/tag-count-pages.txt
Comment 45 Karl Dubost 2011-08-27 04:26:34 UTC
(In reply to comment #44)
> (In reply to comment #43)
> > Same but counting pages instead of elements:
> 
> Forgot the link. http://philip.html5.org/data/tag-count-pages.txt

How many pages were Japanese pages in that sample.
Comment 46 Leif Halvard Silli 2011-09-09 00:32:00 UTC
The editor asked for permission to reconsider this bug before it goes through the CP mill. 

http://www.w3.org/mid/DE1740C7-38FF-4D3D-B768-C9712F089B50@apple.com

And in that regard, I wanted to add some points for his consideration:

(1) Legacy IE support for <rb> is easy to add via the well known 'HTML5 shiv' hack:

    <script>document.createElement("rb")</script>

    The <rb> is in this regard no different from any other element 
    that is unknown to IE. In fact, even if <rb> would *not* be added
    to HTML5, it would still be correct for browsers to treat it as an
    unknown element:

     http://www.w3.org/TR/2010/WD-html5-20100624/obsolete.html#dom-ul-type 

    ]]  
       The bgsound, isindex, multicol, nextid, rb, and spacer elements 
       must use the HTMLUnknownElement interface.
   [[

   Firefox has followed this route for the <spacer> element:

   http://hsivonen.iki.fi/spacer/

   Thus it would be correct, per HTML - even if <rb> is not added to HTML5 as a
   legal element - to ask HTML5 library developers, such as Remy Sharp
   (http://code.google.com/p/html5shiv/) to add support for <rb>. 

   Also, until  HTML5 eventually adds support for <rb>, it would be entirely
   correct of browsers to  let the markup <ruby><rb>a<rt>b</ruby> result
   in the following DOM: <ruby><rb>a<rt>b</rt></rb></ruby>. (Fingers
   crossed.) If I am wrong in that assumption - that they should create the 
   correct DOM regardless, then I can't see that there would be any technical
    reason to not add <rb>.
   

(2) That <rb> isn't very much used as a CSS selector, can be considered an 
     advantage - it means that no one would "break the Web" by enabling 
     support for <rb>.


(3) A use case for <rb>: Rather than styling <rb> itself - as the editor asked
     for examples of, it seems more meaningful to do things like this:

     rb:hover+rt,rb:hover+rp+rt{color:red;/*highlight*/}

     Such styling can be used to show (if <rt> is hidden) or highlight (to identify 
     the <rt> ths is connected with the <rb>) theruby term when the 
     user hover above the ruby base sign.

(4) The Wasting authors time argument: 

     Of course, it would be technically possible to use <span> for this instead. 
     Like it would be tecnically possible to use <span> instead of <dt>.
     However,  it seems to make more sense to the <rb>: AUthors would
     then know its purpose - while a <span> could be used for many 
     functions - thus a <span> would not make immediate sense for 
     someone inspecting the code. Remember as well that code might
     be shuffled around: I could store the content of a definition list
     "outside the Web", for reuse in actual <dl> listes - and in that case
     it would have been quite annoying to have to decide which 
     inline element to use for <dt> - just as it would be annoying to have 
     to decide which inline element to use instead of <rb>.
     
     So, while it *perhaps* would be a waste of time to *require* <rb>,
     it seems also a wast of authors time to force them to pick a 
     random inline element. Such a thing wouild also create a lot more
     "div-it-is" or "span-it-is" (overuse of span/div) looking code,
     in contrast to allowing a dedicated element that everyone know
     the purpose of.
Comment 47 Leif Halvard Silli 2011-09-09 00:58:20 UTC
Ian is probably already aware of Fantasai's article on this: http://fantasai.inkedblade.net/weblog/2011/ruby/
Comment 48 Sam Ruby 2011-09-20 14:37:51 UTC
Reopened by request: http://lists.w3.org/Archives/Public/public-html/2011Sep/0075.html ; associated tracker issue closed (without prejudice)
Comment 49 Murata 2011-09-20 16:43:19 UTC
I sent the following e-mail to public-html@w3.org

>> Bug 10830 was not intended to be WONTFIX, I was sincere in my request for
>> feedback in comment 27. It has since been escalated to issue 172.
>>
>> May I suggest that issue 172 be closed pending the actual resolution of
>> the bug according to the working group process. I would be happy to
>> escalate the bug myself should the bug in fact result in a WONTFIX
>> resolution.
>
>But the project editor claimed:
>
>> Note that despite repeated claims to the contrary, none of the browsers
>> actually support <rb> any differently than any other random element like <foo>.
>
>I think that the HTML WG is the best place to discuss about this
>factual issue, since
>it has implementers of major browsers.
Comment 50 Ian 'Hixie' Hickson 2011-09-21 20:34:08 UTC
Since the main argument here is that <rb> is useful, it would be helpful if people could provide links to pages that actually style the <rb> element or in some other sense make use of it, i.e., evidence that the element is actually useful to authors.
Comment 51 Leif Halvard Silli 2011-09-22 05:05:02 UTC
(In reply to comment #50)
> Since the main argument here is that <rb> is useful, it would be helpful if
> people could provide links to pages that actually style the <rb> element or in
> some other sense make use of it, i.e., evidence that the element is actually
> useful to authors.

I think you should 'cut some slack' due to the bad support for <ruby> - especially for <rb>. This has affected how it is used, I think. It is similar to the bad support for <abbr> in legacy IE. That said, here are some interactive examples:

(1)  ruby:hover rt{hightlight}, see:
     http://sites.google.com/site/funnyepiphany/customize/stylesheet
     This is (merely) evidence that authors want to use interactivity with ruby. To place the hover on rb:hover{} instead of on ruby:hover{} only has the effect that it is more precise in what it hightlight.

(2) Though they (due to the historically bad browser support) use the table element instead of <ruby>, the furiganizer.com hightlights the rubyfied text on hover: http://www.furiganizer.com/     

(3) Furigana injector: http://code.google.com/p/furigana-injector/ 
     This is a browser extension that works with Chrome and and other browsers and which fetches ruby terms from a server and inserts them as ruby annotation via javascript. It uses <rb>. I don't know whether <rb> is important - please analyse.

(4) The yomoyomo.jp site adds ruby on the fly too via javascript, using<rb>:
     Example: http://yomoyomo.jp/content.php?yyparam=00500101&t=

     Neither (3) or (4) use hover styles. But if you try some userCSS and compare the effect of rb:hover{} and and ruby{} hover, then the form only highlights the very text inside the rb element. Whereas if you use the ruby{hover{} it highlights the square area of the entire ruby element. To use rb:hover{} feels more accurate - given that it only focuses on the base word and not the entire ruby element.

(5) http://zh.wikipedia.org/wiki/振假名 This page user ruby and it hightlights the base words with bold style. Unfortuneatly the page uses <b> instead of CSS. Nevertheless, had the author chosen to apply ruby{font-weight:bold} then he would also have had to apply rt{font-weight:normal}, to undoo the styling for the <rt> element. Thus, the keeing the <rb> allows for simpler CSS.
Comment 52 Simon Pieters 2011-09-23 07:39:59 UTC
http://www.google.com/codesearch#search/&q=%5Csrb%5Cs%5B%5E%7B%5D*%7B%20lang:css&type=cs

One sets fallback styles for UAs that don't support ruby but support CSS tables:

ruby rb  { display:table-row-group; display:ruby-base; }


The other sets color, font-size and font-weight

#content_right .content_box h4 rb {
    color:#FFCC00;
    font-size:18px;
    font-weight:bold;
}

...but those are redundant since the h4 has the same color, font-size and font-weight.
Comment 53 Ian 'Hixie' Hickson 2011-09-26 22:41:02 UTC
(In reply to comment #51)
> 
> I think you should 'cut some slack' due to the bad support for <ruby> -
> especially for <rb>.

Asking for just one or two good use cases _is_ cutting some slack. A whole heck of a lot of it. The lack of <rb> isn't actually a limitation for any of the styling suggested here, since an author could just use <span> instead and get the exact same effect.

If there really is a use case here, it would be more than apparent.


> (1)  ruby:hover rt{hightlight}, see:
>      http://sites.google.com/site/funnyepiphany/customize/stylesheet
>      This is (merely) evidence that authors want to use interactivity with
> ruby. To place the hover on rb:hover{} instead of on ruby:hover{} only has the
> effect that it is more precise in what it hightlight.

This seems unaffected by the presence of absence of <rb>.


> (2) Though they (due to the historically bad browser support) use the table
> element instead of <ruby>, the furiganizer.com hightlights the rubyfied text on
> hover: http://www.furiganizer.com/

This page doesn't need <rb> as far as I can tell.


> (3) Furigana injector: http://code.google.com/p/furigana-injector/ 
>      This is a browser extension that works with Chrome and and other browsers
> and which fetches ruby terms from a server and inserts them as ruby annotation
> via javascript. It uses <rb>. I don't know whether <rb> is important - please
> analyse.

I can't find any reason why this would need <rb>, but in any case, it's an extension and therefore need not be limited by HTML.


> (4) The yomoyomo.jp site adds ruby on the fly too via javascript, using<rb>:
>      Example: http://yomoyomo.jp/content.php?yyparam=00500101&t=

This page doesn't seem to benefit from the <rb>. If anything, it makes it more complex.


> (5) http://zh.wikipedia.org/wiki/振假名 This page user ruby and it
> hightlights the base words with bold style. Unfortuneatly the page uses <b>
> instead of CSS. Nevertheless, had the author chosen to apply
> ruby{font-weight:bold} then he would also have had to apply
> rt{font-weight:normal}, to undoo the styling for the <rt> element. Thus, the
> keeing the <rb> allows for simpler CSS.

Actually that page could be simplified even further by removing both the <b> and the <rb> and just styling "ruby > span { ... }".


(In reply to comment #52)
> http://www.google.com/codesearch#search/&q=%5Csrb%5Cs%5B%5E%7B%5D*%7B%20lang:css&type=cs
> 
> One sets fallback styles for UAs that don't support ruby but support CSS
> tables:
> 
> ruby rb  { display:table-row-group; display:ruby-base; }

This could be done using <span> as well, if it was necessary at all (which is unclear to me).


> The other sets color, font-size and font-weight
> 
> #content_right .content_box h4 rb {
>     color:#FFCC00;
>     font-size:18px;
>     font-weight:bold;
> }
> 
> ...but those are redundant since the h4 has the same color, font-size and
> font-weight.

Indeed.


There is not a compelling argument here that there are good use cases for adding this feature.
Comment 54 Addison Phillips 2011-10-07 16:07:43 UTC
The I18N Core WG requests that this bug be re-escalated in Tracker because we seem unable to convince the editor that our use cases are "compelling enough", in spite of implementation support in browsers and broad support for retaining this tag from the affected Japanese community.

This is a consensus I18N WG decision [1] and is I18N-ACTION-74. Previously this was HTML ISSUE-172.
Comment 55 Murata 2011-10-08 00:57:30 UTC
The support of ruby in Internet Explorer is documented in
http://msdn.microsoft.com/en-us/library/ff460533(v=VS.85).aspx.

See "2.2.3   [W3C-RUBY] Section 2.5, The rb element"
Comment 56 Leif Halvard Silli 2011-10-08 01:23:08 UTC
(In reply to comment #53)
> (In reply to comment #51)

It i always possible with an amicable solution. Hence I offer a (belated) reply:
> > (5) http://zh.wikipedia.org/wiki/振假名 This page user ruby and it

> Actually that page could be simplified even further by removing both the <b>
> and the <rb> and just styling "ruby > span { ... }".

How come you see a usecase for 
    <ruby><span>foo</span><rt>bar</rt></ruby>
but not for
    <ruby><rb>foo</rb><rt>bar</rt></ruby>
? 

That <rb> has a dedicated purpose, is an advantage, e.g. it helps avoiding indirection problems.


> (In reply to comment #52)

> > fallback styles for UAs that don't support ruby but support CSS tables:
> > 
> > ruby rb  { display:table-row-group; display:ruby-base; }
> 
> This could be done using <span> as well, if it was necessary at all (which is  unclear to me).

Would a need for *some* elment - such as <span> - convince you about <rb> at all? Or would it simply lead you to say "use <span>"?


> > The other sets color, font-size and font-weight
> > 
> > #content_right .content_box h4 rb {
> >     color:#FFCC00;
> >     font-size:18px;
> >     font-weight:bold; }
> > 
> > ...but those are redundant since the h4 has the same color, font-size and
> > font-weight.
> 
> Indeed.

One could style the ruby text different from the <h4> element. In fact, here is a page which colors some rubified words in red: http://www.biblejapanese.com/july2504.html

> There is not a compelling argument here that there are good use cases for
> adding this feature.

The most obvious use case is when you want to style the base character without affecting the rest of the <ruby>:

* Unless you have <rb> (or another element in its place), there is no workaround:
  ruby:first-line does not work unless you first give the ruby element display:inline-block, which would only lead to a lot of problems (do I need to list them?).  Usiung ruby:first-letter{} has exactly the same problem. 

* A situation where my guess is that many would wants to style the base text-decoration different from the rest, is when the <ruby> is wrapped inside a link, such as here  <http://www.biblejapanese.com/jbibles.html>. It is neither clear or pretty when both the base character and the "above" character both have text-decoration:underline. In fact, to me, as that page looks in Webkit, you easily start to think that there are two links. 

* According to my tests, it is impossible to get browsers to underline only the ruby base character unless there is <rb> or an equivalent element. One must first disable underlineing for the anchor element itself, and then apply a underline only for the <rb> element (or its equivalent element). 

PS: According to http://validator.nu, it is permitted to place an <a> inside the <ruby> element itself - I don't know if that is a bug in the validator, in the spec or in my own understanding of how it ought to be ... But at any rate, I belive that the typical thing to do would be wrap the <ruby> element inside the link, to ensure that the entire line-height as well as the "above" characters are clickable.
Comment 57 Leif Halvard Silli 2011-10-08 05:36:18 UTC
(In reply to comment #53)
> (In reply to comment #51)

>> (4) The yomoyomo.jp site adds ruby on the fly too via javascript, using<rb>:
>>      Example: http://yomoyomo.jp/content.php?yyparam=00500101&t=
>
>This page doesn't seem to benefit from the <rb>. If anything, it makes it
>  more complex.

Thought that page may not examplify it, a use case for <ruby> is this one:


<section lang="native" >Bla bla bla 
      <ruby>
       <rb lang="foreign">bar</rb>
       <rt>bar</rt>
</ruby></section>

Without <rb> (or equivalent), one would have to do this:

<section lang="native" >Bla bla bla 
    <ruby lang="foreign">
        bar
        <rt  lang="native">bar</rt>
</ruby></section>

THus, one must use @lang twice instead of once.
Comment 58 Sam Ruby 2011-10-19 15:52:37 UTC
Removing TrackerRequest.

This missed the September 2nd cut-off for priority requests. The editor has until December 31st to resolve the issue.  If he fails to do so by that deadline, it can be escalated at that time.
Comment 59 Ian 'Hixie' Hickson 2011-11-02 17:10:45 UTC
I spoke with some people in the i18n group about this yesterday, and in particular we discussed the pros and cons of this request. They indicated that they would discuss this further and report back.
Comment 60 Michael[tm] Smith 2011-11-20 18:22:32 UTC
per comment #59, we are waiting for more info from the i18n WG:
> I spoke with some people in the i18n group about this yesterday, and in
> particular we discussed the pros and cons of this request. They indicated that
> they would discuss this further and report back.
Comment 61 Ian 'Hixie' Hickson 2011-11-24 21:56:00 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.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 60
Comment 62 Murata 2011-11-25 02:21:43 UTC
Here I try to provide a factual summary of this issue.   I hope 
that this makes clear that escalation to the WG is the only 
sensible way to go forward.

0) Overall 

The I18N WG has requested HTML5 to allow optional use of the rb element.
Fantasai, Simon Pieters, Koji Ishii, Addison Phillips, Leif Halvard Silli, and I 
have the same opinion.  Ian Hickson is against.

1) Widely used?

The I18N WG and Ishii san believe that rb is very widely used, and have 
provided pointers to supporting evidence.

Yomiuri Online (very common newspaper in Japan)
http://www.yomiuri.co.jp/

Automatic ruby programs
http://mt.adaptive-techs.com/httpadaptor/servlet/HttpAdaptor?.h0.=fp&.ui.=trial&.up.=&.ro.=kh&.st.=rb
http://www.hiragana.jp/

Ian claims that "in practice many pages don't actually use it (the
HTML definition of ruby was based on extensive research for real use
of ruby markup in the wild).", but did not provide any supporting
evidence.

2) Implemented?

Koji Ishii and I believe that the rb tag is widely implemented.

The support of the rb element in Internet Explorer is documented by 
Microsoft in http://msdn.microsoft.com/en-us/library/ff460533(v=VS.85).aspx.
See "2.2.3   [W3C-RUBY] Section 2.5, The rb element"

Ian Hixon claims "IE doesn't support <rb> (it ignores it)", but has not 
provide any supporting evidence.

The best way to make this point clear is to ask browser vendors 
in the HTML WG.

3) Useful or useless?

Fantasai, Simon Pieters, Koji Ishii, Addison Phillips, Leif Halvard Silli, and I 
believe that rb is useful (at least sometimes).  Ian Hickson believes that 
it is always useless.

This point appears to be subjective, and nobody is likely to change
her or his opinion.  I even believe that such religuous debates are
possible for many other HTML5 tags.  Most notably, the dt element in 
definition lists.

When there is a religuous debate, the best approach is to hear 
the opinion from a wide group of experts, implementors, and users.
Dictatorship by the editor is simply not the right approach.
Comment 63 Simon Pieters 2011-11-25 07:46:33 UTC
(In reply to comment #62)
> The I18N WG has requested HTML5 to allow optional use of the rb element.
> Fantasai, Simon Pieters, Koji Ishii, Addison Phillips, Leif Halvard Silli, and
> I 
> have the same opinion.  Ian Hickson is against.

> Fantasai, Simon Pieters, Koji Ishii, Addison Phillips, Leif Halvard Silli, and
> I 
> believe that rb is useful (at least sometimes).  Ian Hickson believes that 
> it is always useless.

The opinion I have stated in this bug is in comment 3. The data presented suggests that authors generally don't style <rb>, however, so I'm not convinced it needs to be added to the language.
Comment 64 Murata 2011-11-25 07:56:29 UTC
My apologies if I misinterpreted your comment, Simon.  Since 
you wrote "However I agree that <rb> would be simpler to use 
compared to <span> (especially if the parser auto-closes <rb>).", 
I thought that you agree to have optional <rb>.
Comment 65 Tony Graham 2011-11-25 11:44:19 UTC
Example of letter-by-letter styling of <rb> in <rbc> in non-CJK text:

http://www.user.uni-hannover.de/nhtcapri/ruby-annotation.html

If more people were aware they could do that, I would expect there would be more of it.

Also shows letter-by-letter styling with simple ruby markup, but if you pretend you're on a mobile device and make the browser window so narrow that the lines with simple ruby break, you'll see the lines with simple ruby can break between any two characters.
Comment 66 Sam Ruby 2011-11-28 14:38:20 UTC
I've reopened http://www.w3.org/html/wg/tracker/issues/172
Comment 67 Ian 'Hixie' Hickson 2011-11-29 19:46:32 UTC
(In reply to comment #62)
> 
> The I18N WG has requested HTML5 to allow optional use of the rb element.

This is outdated information. I had a long meeting with the i18n WG at the TPAC meeting a few weeks ago where we discussed this issue at _length_, and came to the conclusion that <rb> was in fact not only unnecessary, but potentially harmful. Richard took an action item to discuss this further with other members of the working group and report back.
Comment 68 Ian 'Hixie' Hickson 2011-11-29 20:29:13 UTC
(In reply to comment #62)
> 
> Yomiuri Online (very common newspaper in Japan)
> http://www.yomiuri.co.jp/

Here's an example:
http://www.yomiuri.co.jp/national/news/20111129-OYT1T01293.htm?from=main1

The <rb> is not styled and the page would render *exactly* the same if the <rb>s were simply omitted. But they don't need to be omitted, because if browsers continue to ignore <rb> as they do now and as the spec requires, the page will *also* continue to work exactly the same.

This bug in no way negatively affects Yomiuri Online. In fact the spec as it stands now would slightly positively affect them, by making it possible to strip the elements from their markup and thus saving some bandwidth.


> Automatic ruby programs
> http://mt.adaptive-techs.com/httpadaptor/servlet/HttpAdaptor?.h0.=fp&.ui.=trial&.up.=&.ro.=kh&.st.=rb

The only thing this page does with <rb> is style it to not render as native ruby!


> http://www.hiragana.jp/

Again, the only style applied to <rb> here is to not style it as native ruby.

For both the adaptive-techs.com site and the hiragana.jp site, this bug would have no effect whatsoever on the sites. They would continue to work as they do today whether we added <rb> or not. The sites right now are simply relying on the element being treated as an unknown element in browsers.


> Koji Ishii and I believe that the rb tag is widely implemented.

You are wrong. Browsers all treat <rb> the same as <xxx>. This is trivially demonstrable by loading the following in the live DOM viewer:

   <ruby><rb>base<rt>text</ruby>
   <ruby><xxx>base<rt>text</ruby>

Or the following:

   <ruby><rb>base<rt>text<rb>base<rt>text</ruby>


> This point appears to be subjective

It's not subjective. You can list the use cases quite easily, and then see if you need <rb> to do them. You'll find you don't. I've demonstrated this numerous times in this bug already.
Comment 69 Leif Halvard Silli 2011-11-29 22:26:56 UTC
(In reply to comment #67)

> This is outdated information. I had a long meeting with the i18n WG at the TPAC
> meeting a few weeks ago where we discussed this issue at _length_, and came to
> the conclusion that <rb> was in fact not only unnecessary, but potentially
> harmful.

Please share the information about how it is 'potentially harmful'.
Comment 70 Leif Halvard Silli 2011-11-30 06:17:56 UTC
(In reply to comment #68)
> (In reply to comment #62)
  
> The <rb> is not styled and the page would render *exactly* the same if the
> <rb>s were simply omitted. But they don't need to be omitted, because if
> browsers continue to ignore <rb> as they do now and as the spec requires, the
> page will *also* continue to work exactly the same.

You express yourself in a confusing way when you claim that HTML5-compatible UAs ignore <rb>: In fact, elsewhere you say it is  treated like <xxx>.  (It is only in IE6/7/8 that there is no native support even for unknown elemetns.)
 

> This bug in no way negatively affects Yomiuri Online. In fact the spec as it
> stands now would slightly positively affect them, by making it possible to
> strip the elements from their markup and thus saving some bandwidth.

That <rb> becomes included in HTML5 in no way negatively affects this slightly positive side: You are only asked to add <rb> to HTML5 as an optional element. 

In fact, if <rb> is permitted to be unclosed (because it anyway gets autoclosed when it sees <rt> or <rp> - as suggested by Simon and as implemented by Firefox and Webkit), then - for those cases when there *is* a need for a ruby base text element, then <rb> would allow you to save more bandwith than if you were to use <span> - which (according to the authoring conformance rules) requires that you close it manually.)


> > Automatic ruby programs
> > http://mt.adaptive-techs.com/httpadaptor/servlet/HttpAdaptor?.h0.=fp&.ui.=trial&.up.=&.ro.=kh&.st.=rb
> 
> The only thing this page does with <rb> is style it to not render as native
> ruby!
>
> > http://www.hiragana.jp/
> 
> Again, the only style applied to <rb> here is to not style it as native ruby.

Both the above sites use inline table CSS in order to *make* ruby markup work in legacy user agents. And on adaptive-techs.com it works as intended. While on hiragana.jp, the styling seemingly makes things fall apart.

But you make it sound like the problems on www.hiragana.jp, is  linked to its styling of <rb>. However, this is a false insinuation. There is only a problem with the *overall* styling which that site uses in order (which it uses to fix the lacking ruby support in legacy browsers): Removing the <rb> *tags* without also removing the CSS that tries to fix the legacy styling, does not not cure the site's problem. 

Thus it is futile to single out the styling of <rb> as a problem - the real problem is lack of support for ruby markup in legacy browsers in combination with lack of update of the site in face of today's much improved support for ruby markup (in Firefox and Safari/Chrome).  

 
> For both the adaptive-techs.com site and the hiragana.jp site, this bug would
> have no effect whatsoever on the sites. They would continue to work as they do
> today whether we added <rb> or not. The sites right now are simply relying on
> the element being treated as an unknown element in browsers.

When the site launched, it probably relied on *all* the ruby markup elements being treated as unknown elements. Today there is, to various degree, native support for ruby markup in Firefox, Webkit and IE.

So the fact that the site relies on how unknown elements are treated, seems like no argument the one way or the other. If anything, it means that it is technically rather uncomplicated to add <rb> to HTML5.

 
> > Koji Ishii and I believe that the rb tag is widely implemented.
> 
> You are wrong. Browsers all treat <rb> the same as <xxx>. [ snip ]

How UAs treat <rb> an <xxx> - and ruby markup in general, can be seen on this testcase:

 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1264

Results:

(1)  IE6/7/8 treat <rb> like it treats the imaginative, unknown <xxx> element. **However**,  IE6/7/8 does not support unknown elements the way HTML5 requires them to be supported, so it is not comparable to other browsers. (But one can enable HTML5 'unknown element' parsing via the HTML5 shiv method, in which case IE6/7/8 treats it like current Opera and IE9.) IE6/7/8 apply ruby CSS to <ruby>, <rp> & <rt> but don't support ruby parsing (autoclosing when it sees <rt> or <rp>), see (3) and (4) below.

(2)  Opera and IE9 treat <rb> as an unkonwn element. IE9 applies ruby CSS to <ruby>, <rp> & <rt> but doesn't support ruby parsing (see (3) and (4) below). Opera doesn't apply whether ruby parsing or ruby CSS.

(3)  Firefox doesn't apply any styling to <ruby> markup, **but** it does apply ruby *parsing*: if you forget to close the <rb> element (or if you use <span> instead and forget to close it) then the element will be closed once the parser sees the <rp> or <rt> element. Firefox seems to apply ruby parsing since at least version 3.

(4) Webkit (Safari/Chrome) apply ruby parsing, like Firefox does. In addition it applies ruby CSS.


> > This point appears to be subjective
> 
> It's not subjective. You can list the use cases quite easily, and then see if
> you need <rb> to do them. You'll find you don't. I've demonstrated this
> numerous times in this bug already.


Actually, you will find that there are good usecases for <rb>:


   (A)   *When* you want or need to mark up the base text with an element (rather than just placing it direclty inside <ruby>), *then* there is a need for an element that identifies the term that is being translated/rubified as such a thing, so that when you - or someone else - at a later point look up the sourcecode of the page again, you know that the <rb> is there for the purpose of identifing the translated word. Alternatively, if the page were to use <span> instead, then it is hard to know for what purpose <span> was used: Was it for the purpose of working aroudn a browser bug, or did it actually play an important role in the ruby "microformat"? With <rb> in place, there is no question about why it is there.

   (B)   To facilitate simplifed authoring based on ruby parsing:
          An unclosed elements inside <ruby> gets "autoclosed" when the parser sees <rt> or <rp> - this is the case in Firefox and Webkit, and this is what we want the HTML5 parser to do as well [I did not check if HTML5 already says that it shoudl work that way]. Such parsing allows us to say that authors do not need to close the <rb> element - they can rely on automatic closing. For a "new" element, like <rb>, we can without too much trouble introduce the rule that authors *may* skip explicitly closing it with the closing tag. But if authors were required to use <span>, then we would have to abide with the general autoring rule for <span>, which says that the closing tag is obligatory.  (Thus, as noted above, <rb> would save us a tiny bit of bandwith compared to using <span> or even <i> or <b>.)

   (C)   Depending on the script used to write the language, there can be a technical need for identifying the language - and the script - of the translated word via the use of a language tag, and without letting the language inheritance rules affect the rest of the content of the <ruby> element. This can be achieved the simplest by by placing the @lang attribute on the <rb> element as opposed to placing it on the very <ruby> element. In fact, it is *core* to the idea of ruby mark-up that base text  **differs** from annoation text - with regard to language and/or script . And in order to operate with such a separation, then both <rb> and <rt> is needed, so that you can place the @lang attribute on each of them separately rather than on the very <ruby> element, which would affect both base text and annotation text.
  
         Examples - (C):

         1) <ruby lang="foo"> as opposed to <rb lang="foo"> can cause the font styling associated with language "foo" to be applied to both base text and annotation text also when base text and annotation text should rather have different fonts due to use of different writing scripts. This, I'm told, is the case for Firefox.

         2) The lack of <rb> represents a temptation for authors to rely solely on <ruby> and <rt>, which in turn invites to setting the language on <ruby> without overriding the inherited language with a @lang on <rt> too. This could badly affect which language e.g. screenreaders and spell checkers considers the language, script etc of to the content to be. The permission to use <rb> means, in contrast, that there is a natural way to set the language of the base text.

<body lang=nn >Obama, president i
     <ruby lang=en >
         USA
        <rt>Sambandstatane</rt>
     </ruby>
 <!--Above the language of <rt> is set to English due to the use of @lang on the <ruby> element. Whereas in the following element, in the same document, its language is as it should be - nn (Norwegian Nynorsk): -->
     <ruby>
        <rb lang=en> USA
        <rt>Sambandstatane</rt>
     </ruby>
</body>

         3) The content of <rt> will often be in the same language as the text surrounding the <ruby> element. (This because <rt> is often used to explain the content of the <rb>.)  And in that case, if you add the @lang to the <rb> element, you are set - there is nothing more to do: The <rt> inherits the language from the surrounding text:

<body lang=en >Learn some Mandarin:
     <ruby>
        <rb  lang=cmn >&#x6c49;
        <rt>Chinese</rt>
        <rb  lang=cmn >&#x5b57; 
        <rt>character</rt><!--
<rt> inherits language from <body lang=en > =
Thus, authors don't need to restate that <rt> is in English.
 --></ruby>
</body>

SUMMARY:

To *not* allow <rb> means that HTML5 ruby mark-up primarily would cater for the cases when the **base text** should have the same language as the parent element of <ruby>, but not as elegantly for the cases when the **annotation text** should have the same language tag classification as the parent element of the <ruby> have. 

This means that HTML5 ruby mark-up would cater relatively well only for the "Classical" usecase in Chinese or Japanese text, where the "ruby base text character" occurs inside a text of the same language and where <rt> is used to offer an reading/pronounciation aid - <rt> can the be language tagged as needed, while base text would automatically get correct language.  As an example, here is an <ruby> example inside a Chinese document, where it is used in order to  transcribe the  Chinese characters with the bopomofo phonetic script:

<body lang="cmn">&#x6c49;:
     <ruby>
         &#x6c49;
        <rt lang=cmn-Bopo >&#x310f;&#x3122;&#x2cb;</rt>
         &#x5b57;
         <rt lang=cmn-Bopo >&#x3117;&#x2cb;</rt>
     <!--<ruby> inherits language from <body lang=zh > =
     Thus, authors don't need to restate that it is Chinese.
     The <rt> is in same language but different script.-->
     </ruby>
</body>

In a sentence: HTML5 ruby markup without the <rb> element renders HTML5 ruby easy to use for same language annotations, but makes it more difficult to use for annotation of a text segments in another language.
Comment 71 Murata 2011-11-30 09:49:36 UTC
This issue has been escalated to the HTML WG again, and I do not 
think that the HTML WG monitors this issue tracker.  

What is needed to write down a change proposal, as 
shown in http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#escalation-step-2b
Comment 72 Kang-Hao (Kenny) Lu 2011-11-30 15:27:56 UTC
(In reply to comment #69)
> Please share the information about how it is 'potentially harmful'.

I agree this is critical information and I am specifically curious about the cost of making an element that used to be a HTMLUnkownElement to HTMLElement and other harms to authors that I am unaware of at the moment. 

(In reply to comment #63)
> The opinion I have stated in this bug is in comment 3. The data presented
> suggests that authors generally don't style <rb>, however, so I'm not convinced
> it needs to be added to the language.

I am not sure what you mean by "add to the language". If you mean new auto-closing/parsing behavior then I might agree with you and that's the subject of bug 13113. But from the educational perspective, removing <rb> is already not backward compatible (MSDN and the like). Keep telling people "don't look at those specs produced in the dark era" and explaining the history of the specs are not realistic. I just ran into a speaker today who talked about about <ruby> and reference the HTML5 spec but yet used <rb>. I guess they might have been affected by the EPUB work and someone might want to stop them (though that's not me because I support <rb>).

== Authoring Difficulties ==

Again from author's point of view, there are many pair-like constructs in HTML already:

* <dt> <dd> pair in <dl>
* <caption> <tbody> pair in <table>
* <img> <figcaption> pair in <figure>
* <summary> (whatever) pair in <details>

I feel uneasy to have to create the pair-like ruby-base/ruby-text association implicitly by using the parent <ruby> element. It's simply an unusual practice in the HTML language. (This recognition problem might or might not just apply to me given data in Comment 42 and Comment 43)

Also, I had to check the spec to see, for <ruby>AB<rt>C</rt></ruby>, C is the ruby-text for AB instead of just B (bear with me, for Chinese and Japanese, that explanation might work). Normal people won't read the spec.


(In reply to comment #70)
> > > Koji Ishii and I believe that the rb tag is widely implemented.
> > 
> > You are wrong. Browsers all treat <rb> the same as <xxx>. [ snip ]
> 
> How UAs treat <rb> an <xxx> - and ruby markup in general, can be seen on this
> testcase:
> 
>  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1264

Could we please not make the "widely implemented" argument again before we define what "implement"  or "parsing" means here?

> Results:
> 
> (3)  Firefox doesn't apply any styling to <ruby> markup, **but** it does apply
> ruby *parsing*: if you forget to close the <rb> element (or if you use <span>
> instead and forget to close it) then the element will be closed once the parser
> sees the <rp> or <rt> element. Firefox seems to apply ruby parsing since at
> least version 3.
> 
> (4) Webkit (Safari/Chrome) apply ruby parsing, like Firefox does. In addition
> it applies ruby CSS.

If you modify your example to something like <ruby><rb>A<rt>B<rb>C<rt>D</ruby> then the "ruby parsing" won't work in FF8 and Safari 5.1. Although if I understand correctly it might work again because of bug 12935. 



Conclusion: my main argument here is language consistency, although I am more of a XHTML person (whatever that means) and I don't omit tags often so I don't know if my feeling applies to general authors.
Comment 73 Kang-Hao (Kenny) Lu 2011-11-30 15:43:16 UTC
(In reply to comment #72)
> If you modify your example to something like <ruby><rb>A<rt>B<rb>C<rt>D</ruby>
> then the "ruby parsing" won't work in FF8 and Safari 5.1. Although if I
> understand correctly it might work again because of bug 12935. 

Thinking about this again I think this statement is false.
Comment 74 Kang-Hao (Kenny) Lu 2011-11-30 16:04:36 UTC
(In reply to comment #73)
> (In reply to comment #72)
> > If you modify your example to something like <ruby><rb>A<rt>B<rb>C<rt>D</ruby>
> > then the "ruby parsing" won't work in FF8 and Safari 5.1. Although if I
> > understand correctly it might work again because of bug 12935. 
> 
> Thinking about this again I think this statement is false.

So I guess the risk here for allowing <rb> but not changing the auto-closing here is that authors might falsely think <ruby><rb>A<rt>B<rb>C<rt>D</ruby> would work. But is that a real problem given that <details><summary>A<div>B</details> doesn't work either? (though admittedly <ruby> is more like <dl>. One might argue about the inconsistency that <rb> doesn't have the auto-closing behavior of <rt> and <rp>, but we are deprecating <rp>, which I would agree to be a completely useless element, in the long run for authors, so I think this is less like a problem) And you could always do <ruby>A<rt>B</rt>C<rt>D</rt></ruby> instead of <ruby><rb>A</rb><rt>B</rt><rb>C</rb><rt>D</tt></ruby> if we make <rb> optional and you don't need extra tags to make you confident to use ruby.
Comment 75 Richard Ishida 2011-12-08 10:31:55 UTC
Here's a (rather belated) summary of what came out of the discussion 
between the i18n WG and Ian at TPAC.

Ian had not realised that we wanted rb to be only an optional tag. This 
initially made some difference to his amenability to consider it's use. 
We, on the other hand, realised that we hadn't properly thought through 
whether you could achieve ruby styling using span (which will be allowed 
inside ruby in html5).

We discussed the legacy question, but found it hard to argue for rb 
solely on that ground, since other things have been discontinued in 
html, and certainly we agreed that the html5 model is easier to use, in 
general, than the old model (because it reduces the markup overhead for 
the content author).  The question is whether we need rb for particular 
use cases.

Ian was open to hear technical arguments for retaining rb. Much of the 
discussion at that time centred around the possible need for rb to 
support complex ruby. We reviewed the use cases for complex ruby with 
Ian, but we believe that we don't yet have a clear answer as to whether 
rb is required in order to achieve the goals of complex ruby (ie. ruby 
on both sides, and association of rt with rb). We agreed that we needed 
to investigate that (which will entail better understanding how we could 
achieve the effects of complex ruby in html5) and the pros and cons of 
using span, and put our findings to Ian. (see comment 59).

Since then we have realised that there may be some other use cases, such 
as replacement of ruby base text with ruby text, or aggregation of ruby 
texts within parens for jukugo ruby, that we overlooked in our discussion.

Note that the WG, during our discussion, didn't come to Ian's conclusion 
in comment 67 that "<rb> was in fact not only unnecessary, but 
potentially harmful", but we did feel that we needed to do further 
research into the pros and cons for the use of rb. As Ian also says in 
comment 67, "Richard took an action item to discuss this further with 
other members of the working group and report back". We have begun this 
process, and are hoping to continue along that route without having to 
resort to the adversarial jousting competition that escalation often 
entails.

To that end, we would like to consolidate the various technical 
arguments put forward for rb, ensure that they are investigated more 
thoroughly where needed, and more clearly draw out the pros and cons for 
its use.
Comment 76 Richard Ishida 2011-12-18 18:42:08 UTC
In an attempt to help this discussion forward i have prepared a wiki page. It attempts to state use cases, and from there to show alternative proposals for addressing those use cases (with examples). For each proposal there is a short summary of pros and cons.

See http://www.w3.org/International/wiki/Rb

This looks at the question of whether rb is needed by taking into account the larger perspective of the ruby model.

There is also a new set of tests, with results summarised for major desktop browsers, at http://www.w3.org/International/tests/html-css/ruby/results-ruby-markup (Most of the tests are exploratory in nature.)

From doing this exercise, I am beginning to lean towards the following views:

a. legacy usage of rb is not a strong persuader for adding rb to html5
b. we can probably do without rb for simple ruby (since we can use span inside html5 ruby). This includes jukugo ruby.
c. we have a couple of options to follow for supporting double-sided (ie. complex) ruby. This impinges also, however, upon the handling of fallbacks, which is currently an issue with the html5 model. Fantasai proposes a model which provides a simple, consistent solution to both problems, but which does require the introduction of rb (and rtc). There may be a number of workarounds that could be cobbled together for double-sided ruby if we absolutely want to avoid rb, but they don't solve the fallback issue.
Comment 77 Leif Halvard Silli 2012-01-05 14:36:31 UTC
I offer this Change Proposal: http://www.w3.org/html/wg/wiki/IncludeRB

Note: I still work on it.