- From: Robin Berjon <robin@w3.org>
- Date: Thu, 23 Jan 2014 11:09:56 +0100
- To: Ian Hickson <ian@hixie.ch>
- CC: "www-style@w3.org" <www-style@w3.org>, kawabata taichi <kawabata.taichi@gmail.com>
> 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