W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2011

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

From: <bugzilla@jessica.w3.org>
Date: Thu, 17 Feb 2011 03:38:28 +0000
To: public-i18n-cjk@w3.org
Message-Id: <E1PpuhI-0007yP-P9@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10830

Koji Ishii <kojiishi@gluesoft.co.jp> changed:

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

--- Comment #12 from Koji Ishii <kojiishi@gluesoft.co.jp> 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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You reported the bug.
Received on Thursday, 17 February 2011 03:38:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 17 February 2011 03:38:31 GMT