Re: [css-ruby] Should CSS Ruby be consistent with HTML5 Ruby?

> On Tue, 7 Jan 2014, kawabata taichi wrote:
>> Currently, the HTML specification for Ruby is on the way of revision in
>> new github branch by Robin (https://github.com/w3c/html/tree/new-ruby),
>> and it will be incorporated into the new Ruby Extension Spec
>> (http://darobin.github.io/html-ruby/) and eventually into HTML5.
>
> For the record, I think this is a huge mistake. It doesn't actually
> address any more use cases than the HTML standard, at least not any listed
> here:
>
>> ruby use cases (http://www.w3.org/TR/ruby-use-cases/)
>
> All it does is make the brief transition period mildly better for users of
> legacy browsers in some less common cases

Actually, it is a common mistake to believe that <rp> and inlining are 
only useful as fallback for browsers that do not support ruby. The ruby 
use cases document you point to actually mentions that (though it could 
go into further details).

Inlining can be required when the line-height is insufficient to 
position ruby annotations readably compared to the base other than by 
inlining them. Similarly, the case can arise when the font-size is too 
small.

Inlining is also required in order to cut and paste ruby content as 
text. If the HTML document cannot provide properly ordered inlined text 
then you either lose annotations or get gibberish. Neither option is 
desirable.

> while dramatically increasing the complexity of the markup. This is
> bad for authors.

The complexity of the markup does not increase. Simple cases remain 
simple, some complex cases become clearer, and new use cases become 
possible.

> The HTML standard's approach uses common HTML conventions like nesting to
> handle the same use cases while keeping the overall markup language's
> surface area smaller, which makes it easier for authors to approach.

The way that the WHATWG HTML LS uses nesting of <ruby> element to 
sometimes annotate a ruby base and sometimes annotate a ruby run is very 
much akin to replacing <td> with <tr>.

Sure enough, a table cell is pretty much a row inside a row. Assuming 
for a second that we were designing <table> from scratch so that the 
parser made this possible, we certainly could have:

   <table>
     <tr>
       <tr>Bender</tr>
       <tr>Shiny</tr>
       <tr>Bitable</tr>
     </tr>
   </table>

Represent, as it were:

   +--------+-------+---------+
   | Bender | Shiny | Bitable |
   +--------+-------+---------+

It would certainly keep the overall markup language's surface area 
smaller, make it for one fewer element for authors to approach, possibly 
reduce parser churn, and handle the same use cases. In fact, it would 
liberate a horde of new use cases: by nesting <tr> further we could have 
not just tables but cubes and even hypercubes. We could perform 
n-dimensional manifold analysis with just jQuery and replace cumbersome 
WebGL with 3D table layout.

Still, I reckon <td> was the way to go because a cell is only a row's 
row in an abstract sense that does not relate to how people understand 
tables.

The same applies to ruby.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 23 January 2014 10:10:06 UTC