W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[Bug 10830] i18n comment : Please add support for rb

From: <bugzilla@jessica.w3.org>
Date: Tue, 15 Feb 2011 01:35:51 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Pp9pX-0000o6-5P@jessica.w3.org>

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #11 from Ian 'Hixie' Hickson <ian@hixie.ch> 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

> 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:

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.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 15 February 2011 01:35:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC