W3C home > Mailing lists > Public > www-style@w3.org > November 2014

Re: [css-ruby] spanning of ruby annotations across excess bases

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Mon, 10 Nov 2014 10:58:15 +1100
Message-ID: <CAMdq69_ueSFLwJRMkYxdn8fRgdfAze7NYykRVGWOJHkaBuovDg@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style list <www-style@w3.org>, www International <www-international@w3.org>
On Sun, Nov 9, 2014 at 9:25 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:

>
> On Sun, Nov 9, 2014 at 5:42 AM, L. David Baron <dbaron@dbaron.org> wrote:
>
>> http://dev.w3.org/csswg/css-ruby/#base-annotation-pairing says:
>>   # If there are not enough ruby annotations in a ruby annotation
>>   # container, the last one is paired with (spans across) any excess
>>   # ruby bases. (If there are not any in the ruby annotation
>>   # container, an anonymous empty one is assumed to exist.)
>>
>> Is there actually a use case for this behavior, or is it really just
>> defining error handling?
>>
>
> I guess they have, for example, an English word spans several kanji along
> with their kana. Or a multi-kanji word with two different pronunciation,
> one for kun'yomi, the other for on'yomi.
>
> I ask because I think it adds substantial extra complexity,
>> especially around line-breaking of ruby.  If there isn't a good use
>> case for it, I would prefer if ruby annotation containers that do
>> not have enough annotations simply not provide annotations for the
>> final bases, instead of having their final annotation span all the
>> remaining bases.
>
>
> I want to add that, the spanning rule here not only increases the
> complexity on line-breaking, but also make it difficult to define space
> distribution behavior for alignment. You can see issue 9 in the current
> draft.
>

In addition to the issues mentioned above, I suspect that it would also
affect 'ruby-position: inter-character', which does not support any
spanning when the directions are orthogonal.

- Xidorn
Received on Sunday, 9 November 2014 23:59:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC