Memo from ruby disucssion with Roland

I had some technical discussions and brain storming with Roland last week, and here's what we discussed. We didn't reach any concrete conclusions yet, but it gave me some hints to go forward, and I thought sharing this at this ML would help our discussions.

We first discussed some use cases. Roland asked how often complex ruby is used. I told him that 0.16% of Aozora Bunko novels had double-ruby[1], which was higher than his expectation. He was also interested in "rbspan" as it introduces some implementation complexity, so we then discussed Harry Potter example[2], where base consists of Kanji and Kana, reading applies only to Kanji while meaning applies to the whole word. I think it made sense to him.

We then discussed fantasai's idea to look at ruby issues in two different approaches; "row-major v.s. column-major." Here's some explanation of the "row-major v.s. column-major" concept as I understand.

The normal layout of ruby, as we all know, is like this:
  R1 R2 R3
  B1 B2 B3
where R* are ruby text, and B* are base text. Each component has one or more characters. Each R* is paired with its corresponding base. Sometimes components can be merged horizontally. Sometimes there could be another additional row, like the example below:
  R1 R2 R3
  B1 B2 B3
  r1 r2 r3
where r* is another row.

These properties of ruby let Ruby Annotation[3] designers to take "row-major" approach; split first by rows and then by columns. This is similar to HTML tables (the precise design is different, but I think Ruby Annotation belongs to "row-major" approach.)

Another approach, "column-major," is to split first by columns and then by rows. There are some such examples in the wiki[4], and also Ian suggested in his comment #17 of bug 13113[5]. This design is similar to inline boxes, and in general, browsers perform better for inline boxes than for tables.

In short, elements appear in row-major approach in this order:
  B1 B2 B3 R1 R2 R3 r1 r2 r3
while they appear in column-major approach:
  B1 R1 r1 B2 R2 r2 B3 R3 r3

When rendering these elements in ruby style, column-major approach has advantages. In row-major approach, when parser reads R1 or R2, if they're long at the line end, B2 or B3 may need to be sent to the next line. But in column-major approach, each box completes its layout as parser reads elements.

On the other hand, since HTML is a semantic representation, we need to consider other layout capabilities. One example is CSS ruby-position:inline[6]. In this case, users expect to see:
  B1 B2 B3 (R1 R2 R3)
which is similar to what fantasai wrote as "Fallback"[7] and then we discussed as Fallback issue in wiki[8]. In this case, the benefits is on row-major. Column-major requires re-ordering of boxes and may require re-layout on the line end. Roland's impression was that, if browsers are going to implement this re-ordering, there will be more severe issues than re-layout issue in ruby style layout of row-major approach.

There are some more brainstorming of how to display ruby on screen in Japan, because sometimes ruby text is too small to read on screen when zoomed-out, or on mobile phones. They include inline and popup. Although they're just still brainstorming ideas, but row-major seems to work better for popup as well.

Roland brought up yet another idea, using "for" attribute, like <label for="id">. The implementation may be more complicated than the two, but this approach can avoid using rbspan, which he didn't like. He didn't like rbspan because it makes box generation code complicated when elements are inserted/deleted dynamically. For example, <rt for="B1 B2"> can avoid rbspan and tighten the relationship between base and ruby than rbspan does, although we need to define behaviors more precisely (e.g., what happens when B4 is inserted between B1 and B2, etc.) I still haven't gave much thoughts on the idea yet, but it's probably worth to investigate further.

The meeting ended without any conclusions, but from this discussion, I think row-major seems to be better solution if we consider both ruby style and inline style. Column-major seems to be better if we give up inline, and we need further investigation for id-based approach.

Whether we can give up inline or not is a hard question. In my feeling at this point, I can live without fallback if it's expensive, but it's really hard to give up inline. I may conclude differently as I investigate each approach and id-based approach further though.

[1] http://www.w3.org/International/wiki/Rb#Real_Examples
[2] http://fontworks.co.jp/font/knowledge/image/caption_cont02_img02.gif
[3] http://www.w3.org/TR/ruby/
[4] http://www.w3.org/International/wiki/Rb
[5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=13113#c17
[6] http://dev.w3.org/csswg/css3-ruby/#rubypos
[7] http://fantasai.inkedblade.net/weblog/2011/ruby/#fallback
[8] http://www.w3.org/International/wiki/Rb#3_Fallback_for_multiple_bases_in_one_paren

Regards,
Koji

Received on Saturday, 18 February 2012 13:29:11 UTC