Re: Memo from ruby disucssion with Roland

Hello Roland,

On 2012/02/22 13:37, Roland Steiner wrote:
> Sorry for chiming in late to this thread!
>
> Koji summed up our discussion pretty well, I think. There's just one thing
> I wanted to add to the reasoning of the 'for' approach for clarification:
>
> With 'rspan' or<rtc>, there is no semantic link from the base to the
> text(s). For example:
>
> <ruby><rb>東<rb>京<rtc>とうきょう</ruby>
>
>
> and similar with 'rspan' - in this case, even if you add, remove or edit
> the bases dynamically, the ruby text will always be 'とうきょう'. This is what I
> wanted to address with the 'for' attribute: the text would only be rendered
> if the bases it refers are present within the same ruby, and rendered in
> the order it refers them. E.g.
>
> <ruby><rb id=T>東<rb id=K>京<rt for="T K">とうきょう</ruby>
>
> In this case, 'とうきょう' should only be rendered if there are the bases 'T'
> and 'K', consecutively, in that order. If, for example, the base for '東' is
> removed, the text would no longer be applicable, and thus not rendered.
> Neither would it be rendered if 'T' or 'K' are not the id of a<rb>  within
> the same ruby.

What exactly would such a functionality be good for? I don't really see 
the average JavaScript hacker to change the text underlying some ruby. I 
also don't see the point of having the ruby text 「とうきょう」in there 
waiting for the moment somebody inserts a base with identifiers T and K 
again.

> Now, I fully admit, that this is very verbose may not be all that
> necessary. It also doesn't help if the innerText of the bases is changed.
> Implementation is also tricky. OTOH, the advantage would be that a<rt>
> does not have to neighbor a base.
>
> The whole idea came from a discussion to alternatives to markup. That is,
> for some use cases it would be nice to be able to generate ruby texts by
> CSS rather than having to repeat markup. Along the lines of:
>
> rb.東::ruby-text {
>      content: "とう";
> }

This would use a class attribute. It's possible in theory, but because 
the character 東 isn't always pronounced the same (which is the original 
need for ruby), it won't really scale. I can much more easily imagine 
classes being used e.g. to indicate readability levels. As an example, 
each ruby text would include a class attribute saying which grade this 
pronunciation is learned, and there would be different stylesheets for 
different grades, switching off ruby display for those characters where 
the pronunciation is supposed to be known.

Regards,   Martin.

> Cheers,
>
> - Roland
>
>
> On Mon, Feb 20, 2012 at 14:23, Koji Ishii<kojiishi@gluesoft.co.jp>  wrote:
>
>> 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 Wednesday, 22 February 2012 05:45:11 UTC