W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [css-ruby] White space collapse between ruby annotations

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Thu, 16 Jul 2015 19:07:31 +1000
Message-ID: <CAMdq69_+_MBTfEU4VoqWVEyBxw-reHdG+b4F7XEE0XJ58Y6XvQ@mail.gmail.com>
To: Koji Ishii <kojiishi@gmail.com>
Cc: "Myles C. Maxfield" <mmaxfield@apple.com>, www-style list <www-style@w3.org>
On Thu, Jul 16, 2015 at 5:06 PM, Koji Ishii <kojiishi@gmail.com> wrote:

>
> On Sat, Jul 11, 2015 at 4:13 AM, Myles C. Maxfield <mmaxfield@apple.com>
> wrote:
>
>> Ruby runs are partitioned by <rb> elements. Therefore, in your example:
>>
>> > <ruby>
>> >   <rb>a</rb><rb>b</rb>
>> >   <rt>x␣</rt><rt>␣y</rt>
>> > </ruby>
>>
>> The first run has a base of "a" with no ruby text.
>> The second run has a base of "b" with two ruby texts, "x␣" and "␣y"
>> In this case, I believe it makes sense to collapse the whitespace between
>> the "x" and the "y."
>>
>
> rb and rt are connected by their indexes, so in this example, "a" has "x␣"
> and "b" has "␣y".
>
> In your third example:
>>
>> > <ruby>
>> >   <rb>a</rb><rt>x␣</rt><rb>b</rb><rt>␣y</rt>
>> > </ruby>
>>
>> The first run has a base of "a" with a text of "x␣"
>> The second run has a base of "b" with a text of "␣y"
>> In this case, I believe it doesn't make sense to collapse the whitespace
>> between the "x" and the "y."
>>
>
> Yeah, so Xidorn's point is that two different way to write markup for the
> same semantics causing difference, which does make sense to me.
>
> Is this from real use cases? While it logically makes sense, I guess the
> use of spaces in ruby is rare, and putting spaces at the begin/end of <rt>
> is even rarer that I'm not excited to add special casing here.
>

No, not from real use cases. I noticed this when I was fixing some bug
related to ruby with whitespace, and the behavior I proposed is what Gecko
currently implemented.

- Xidorn
Received on Thursday, 16 July 2015 09:08:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC