- From: Richard Ishida <ishida@w3.org>
- Date: Thu, 14 Feb 2013 06:33:23 +0000
- 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 <ruby><rb>上<rt>じよう<rb>手<rt>ず</ruby> >> >> 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 text. 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 W3C http://rishida.net/
Received on Thursday, 14 February 2013 06:34:36 UTC