W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > July to September 2010

Re: HTML5 bugs to be raised

From: KangHao Lu (Kenny) <kennyluck@w3.org>
Date: Wed, 29 Sep 2010 06:02:58 +0900
Message-Id: <34A901C5-00A0-446C-85DF-2106A912B03B@w3.org>
To: CJK discussion <public-i18n-cjk@w3.org>

> -	Request for support for optional rb in HTML5 markup

+1 for raising this issue.

Some other reasons besides making most existing uses conformant (which  
is an argument that's strong enought IMHO) are:

- (brought up by fantasai) Adding <rb> allows fine control over line  
breaking in <ruby> by

   rb { white-space: no-wrap }

- It allows a UA that doesn't support 'display: ruby' to use 'display:  
inline-table'. However this only works if there is only one <rb><rt>  
pair in each <ruby>

Notice that in Section 10.2.2 Display Types of the HTML5 spec[1]  
there's this statement

For the purposes of the CSS ruby model, runs of children of ruby  
elements that are not rt or rp elements are expected to be wrapped in  
anonymous boxes whose 'display' property has the value 'ruby-base'.

so I am quite optimistic about this change to be made.

FYI, I discovered a ruby document on MSDN revised recently for IE9 [2]  
which makes the following clarifications to the XHTML ruby document

All rb elements within simple or complex ruby elements are displayed.

No error handling occurs for an rb element with a descendant ruby  


All rbc elements within ruby elements are displayed.

Which seems to me that it implies IE9's support of complex ruby!? The  
difference from the spec is that multiple ruby texts are allowed in a  
<ruby>, and it seems like a combination of XHTML5 Ruby and HTML5 Ruby.

Anyone tested this yet?

[1] http://www.w3.org/TR/html5/rendering.html#display-types
[2] HTML: http://msdn.microsoft.com/en-us/library/ff460533%28v=VS.85%29.aspx
       PDF: http://download.microsoft.com/download/8/4/2/8427CF1B-08B3-4557-952D-102E7A8FA64C/%5BMS-RUBY%5D.pdf
Received on Tuesday, 28 September 2010 21:03:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:59:14 UTC