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

RE: Memo from ruby disucssion with Roland

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Mon, 20 Feb 2012 00:23:20 -0500
To: fantasai <fantasai.lists@inkedblade.net>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0D334EFCF2@MAILR001.mail.lan>
That's an interesting idea, I guess I missed that part when I read your blog last time.

I like your idea to limit the spans to all or none. I agree the case you raised is very rare, so I don't think we need to support it. I would like it be expressed as rbspan="*" and don't allow arbitrary numbers for now, but your idea might be more acceptable for simplicity.

What I learned from the discussion with Roland was, manipulating DOM and supporting edge cases are harder than creating box models from normal elements. From your proposal, I wonder:
1. What will happen if author writes <rtc>abc<rt>def</rt></rtc>
2. What will happen if author writes <rtc>abc</rtc>, and then insert <rt> as a child of <rtc>

For id-approach, your response is understandable, Roland was aware of that. One of the cons of row-major approach is that, the parings of rt and rb are weak (just indexes) and therefore when rt or rb is inserted to DOM via JavaScript, UAs must shift all the parings of rb/rt boxes after the insertion point. That'd be a bit of code, and also it isn't easy for JS developers to correctly handle. His id-approach is one idea to avoid that, knowing it has other problems. I think he wants a bit more brainstorming if there were really no good idea to strength the pairing during the DOM manipulations. The best one so far was id-approach, which has other problems as you pointed out, so maybe we have to live with this, but I just want to keep in mind that this is a cons of row-major approach.


Regards,
Koji

-----Original Message-----
From: fantasai [mailto:fantasai.lists@inkedblade.net] 
Sent: Sunday, February 19, 2012 7:49 PM
To: public-i18n-cjk@w3.org
Subject: Re: Memo from ruby disucssion with Roland

On 02/18/2012 02:28 PM, Koji Ishii wrote:
> He didn't like rbspan because it makes box generation code complicated when elements are inserted/deleted dynamically.

Hi Koji,
I don't think there's a need for rbspan if you want to do this

  group-note
B1 B2 B3 B4
T1 T2 T3 T4

See http://fantasai.inkedblade.net/weblog/2011/ruby/ Level 3: Double Ruby - the idea is that text contained directly within an <rtc> is interpreted as spanning all bases.

There's only need for rbspan if you want to do this

span-1-3 T4
B1 B2 B3 B4
T1 span-2-4

I haven't seen any examples of this, have you? I don't imagine it would be at all common...

> 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.  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.

This is awkward to author, and makes possible some very strange markup that makes no sense. Suppose someone puts in IDs for non-consecutive bases. Or bases from the previous line. Or the ID attribute of a <div>.

(IMO, interfaces should be designed, insofar as practical, so that invalid or nonsensical input is simply not possible. This fails that test...)

Thank you for the discussions and the summary!

~fantasai
Received on Monday, 20 February 2012 05:23:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 February 2012 05:23:49 GMT