Re: Memo from ruby disucssion with Roland

On Wed, Feb 22, 2012 at 14:44, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>wrote:

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


Mainly to decouple bases and text - e.g., to allow for fall-back:

    <ruby><rb id=T>東<rb id=K>京<rp> (<rt for=T>とう<rt for=K>きょう<rp> ) </ruby>

and to provide layout flexibility, e.g., when switching to bopomofo ruby:
render <rt> that applies to a single base to the right, but text that
stretches several bases below (or some such). However, this notation as is
would play havoc on fallback to current HTML5 ruby, so I'm not entirely
convinced myself it's such a good idea.

As for changing the underlying ruby via JavaScript: whether or not it's
common is not relevant from an implementation point of view, but that every
possible configuration and operation is defined and handled correctly,
including intermediate states that may happen during larger DOM
manipulations (as in my example), or even nonsensical combinations.


Cheers,

- Roland