W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2013

Re: Fwd: Re: HTML Ruby Extension

From: Richard Ishida <ishida@w3.org>
Date: Thu, 14 Feb 2013 06:33:23 +0000
Message-ID: <511C8533.6080709@w3.org>
To: "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>
> Email from Fantasai, forwarded with permission.
> -------- Original Message --------
> Subject: Re: HTML Ruby Extension
> Date: Tue, 12 Feb 2013 23:28:28 -0800
> On 02/12/2013 10:17 AM, Richard Ishida wrote:
> ...
>> [2] a more significant issue:
>> I think the markup proposed for jukugo ruby is too complicated for the
>> general case
>> <ruby><rb>上<rb>手<rt>じよう<rt>ず</ruby>
>> should just be
>> <ruby>上<rt>じよう</rt>手<rt>ず</ruby>

or the much easier to grok


>> jukugo ruby is just mono-ruby - it's the styling that makes the
>> difference,
>> by allowing slightly more complicated overlapping than you would for
>> mono-ruby.
> While it is true that jukugo ruby and mono ruby are stylistic variants
> of each other when applied to a single word, my understanding is that
> in the case where ruby can be combined into a jukugo rendering, you
> also want the annotations combined when rendered inline.

That's certainly preferable, but see below...

>> At the very least you should state this, and not leave people thinking
>> that they
>> have to use a tabular approach for jukugo base text.
> This would mean having two different CSS models (one column-based,
> one row-based) for ruby. Is it necessary to allow both variants?
> Can you give me an example where jukugo ruby is appropriate but
> split inlining is preferable?
>> But if you mark it up like that you won't get what you want at all,
>> surely. You'll get 東京とうきょう with no parens.
> If you assume that a renderer will either:
>    - handle ruby markup intrinsically or
>    - support CSS2.1 generated content
> then you can deal with the parens that way rather than adding them
> explicitly to the markup. The necessary information is there in the
> markup already.
> Unfortunately because of limitations in Selectors (they completely
> ignore text nodes), you'll have to use <rb> to get the parens
> generated correctly via CSS2.1. :/

It worries me in that the very small tail of inline placement is wagging 
a large dog of markup changes here.

If a renderer is expected to know how to handle markup intrinsically for 
applying parens, as you say, why can't it automatically rearrange the 
content for display when inline ruby is required? (It doesn't seem that 
it would be particularly hard to do - see my little utility at 
http://rishida.net/code/inlineruby/ that does it using a trivial bit of 
javascript).  That way we can also avoid having two different CSS 
models, and make authoring simpler too, n'est-ce pas?

Bear in mind that the browser will have to do some fancy footwork with 
the rb.rb.rt.rt model anyway in order to deal with line breaking, since 
a jukugo can be broken in the middle of the word. In that case the 
appropriate rt text must be moved to the next line block, with the base 

By the way, I think you are proposing the introduction of a second CSS 
model yourself, since I believe we need to support the current HTML 
simple ruby model, which allows rb.rt.rb.rt... This is because (a) it 
has already been out there for some time and we risk breaking sites if 
we move away from it, and (b) because it's much easier to author simple 
stuff using that model.  I can't see it going away.

Adding an rb.rb.rt.rt approach for double-sided ruby support may be 
doable, since implementation of the current proposal in HTML5 is not yet 
addressed afaik.  Adding an rb tag for styling simple ruby may also be 
doable, since it doesn't change the model. But proposing the rb.rb.rt.rt 
model for simple ruby seems to be introducing just the thing you are 
worried about.

Richard Ishida
Received on Thursday, 14 February 2013 06:34:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:10:24 UTC