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: Wed, 12 Nov 2014 09:34:13 +1100
Message-ID: <CAMdq699FKtE_eZSooCYW_8E6rV2Wxje+Bk-qiYiQ9rrRN_EmRA@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Wed, Nov 12, 2014 at 3:39 AM, fantasai <fantasai.lists@inkedblade.net>

> On 11/08/2014 01:42 PM, L. David Baron 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?
> It's to handle HTML5 spanning ruby markup:
>   <ruby><rb>旧<rb>金<rb>山<rt>jiù<rt>jīn<rt>shān<rtc>San Francisco</ruby>

Yes, there is such thing in W3C HTML5, but not in WHATWG HTML5. And I don't
think it is really a common use case.

>  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.
> What is the complication wrt line-breaking, and how is it better
> to use nested markup?

Spanning adds many branches when dealing with line-breaking, while we don't
need them with nested markup.

OTOH, as I mentioned before, spanning also introduces complexity in many
other aspects, like spacing distribution and interaction with

- Xidorn
Received on Tuesday, 11 November 2014 22:35:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:48 UTC