W3C home > Mailing lists > Public > www-international@w3.org > January to March 2010

Re: Ruby in HTML5

From: Suzumizaki-Kimikata <szmml@h12u.com>
Date: Sun, 14 Mar 2010 20:02:48 +0900
To: Roland Steiner <rolandsteiner@google.com>
Cc: MURAKAMI Shinyu <murakami@antenna.co.jp>, Takuya Oikawa <takuya@google.com>, Jeroen Ruigrok van der Werven <asmodai@in-nomine.org>, Richard Ishida <ishida@w3.org>, www-international@w3.org, public-html-ig-jp@w3.org
Message-Id: <20100314200248.80dda5b8.szmml@h12u.com>
Thank you very much to explain what is the problem to implement complex
ruby annotation. Your information is helpful to understand the problem.

On the other hand, I think you have 'double-misunderstood' about the
needs of the ruby.

1) Did the first HTML begin to resolve just academic requirement,
didn't it? I think we should not kill the request by its 'academicity'.

2) The needs of complex rubys are simply not academic. The kinds of
needs are for educational (as I told before in this list) or for
entertainment, like novels for the ordinary people.

But I have understood now the current specifications around the
ruby-annotation are not enough in several points. It seems hard to
implement WITH CSS or javascript, at least currently.

Yes... I think that can be the limit of the capability of the layout
model of CSS, if I believe your notes. Not the problem of the ruby.

Anyway, we should take the good idea to make the implementers happy, of
course the ruby users too. 

Suzumizaki-Kimitaka <szmml@h12u.com>
JPN: 鈴見咲 君高

On Fri, 12 Mar 2010 19:28:00 +0900
Roland Steiner <rolandsteiner@google.com> wrote:

> Let me add a few thoughts as the author of the current WebKit implementation
> of ruby, which based on the HTML5 spec. Now, that implementation has much
> room for improvement, so any discussion on how to improve and - more
> importantly - converge the standards is very useful, and much needed IMHO.
> The following is all from an implementation point of view. I have also
> raised some of the points below in another discussion "Ruby proposal for XSL
> 2.0" in the www-style mailing list.
> o) Mono, Jukugo and Group ruby
>  HTML5 syntax would lend itself very easily to all of them, without any
> additions:
>     Mono ruby:   <ruby> 東 <rt> とう </rt></ruby><ruby> 京 <rt> きょう </rt></ruby>
>     Group ruby:   <ruby> 東京 <rt> とうきょう </rt></ruby>
>     Jukugo ruby:   <ruby> 東 <rt> とう </rt> 京 <rt> きょう </rt></ruby>
> o) Complex ruby, nested ruby:
> As I see it, there are several "levels" of complex ruby support:
> 1.) allow the (single) ruby text to be positioned below the base
> 2.) allow 2 ruby texts, both above and below the base at the same time
> 3.) allow multiple ruby texts above and below the base (not in any spec, but
> raised in this discussion)
> 4.) allow ruby texts both above and below the base, allow different spanning
> of those texts relative to ruby base elements
> The first should be rather easy and straight-forward to implement by adding
> 'ruby-position: after'.
> The 2nd could be handled by nested ruby. But while I think that nested ruby
> _should_ work in a browser from a technical point of view (as in "why
> not?"), I don't think it should be the preferred solution for this.
> On the other hand, complex ruby as described in the current CSS3/XHTML spec
> addresses the 2nd and 4th item, but is IMHO too technical a solution. It
> requires too much markup for something that conceptually is rather simple.
> It has much of the complexities of tables, while also being subtly
> different. Due to the way tags are nested, <rp> elements cannot be used in
> complex ruby, which is counter-intuitive and WILL lead to mistakes (see,
> e.g., http://www.crosswire.org/pipermail/sword-devel/2008-July/028644.html).
> As mentioned in the Bugzilla thread
> https://bugzilla.mozilla.org/show_bug.cgi?id=256274, esp. comment #7, the
> current complex ruby spec also lacks specifics for error handling. The
> Bugzilla thread mentions illegal or non-text-flow elements within the
> various ruby containers. Another problem would be how to treat 'ruby-span'
> when the value is too large, or is being dynamically changed by JavaScript.
> The spec also does not address cases that may well occur in HTML outside of
> simple text layout, e.g., handling 'ruby-overhang' when the adjacent
> elements are of different sizes, positioned, animated, etc. (Indeed I
> believe that 'ruby-overhang', while typographically very nice, will prove to
> be the hardest part to implement properly).
> In general, the use cases put forward in this thread seem to mainly ask for
> the first 2 items in above list. There does not seem to be a real need for
> item 3., although I believe any implementation that properly supports item
> 2. should rather easily be extensible to also support item 3., but that
> could be mistaken. Even then, this could really be a case to use nested
> ruby. Item 4. is addressed by the complex ruby spec, and should likewise be
> extensible to include item 3. However, both item 3. and 4. seem to me rather
> academic enough to consider foregoing them if it can result in simpler
> markup instead.
> In summary, I personally would rather prefer a discussion on how the HTML5
> and CSS specs could be converged without introducing unnecessary
> complexities.
> o) Ruby properties
> As also suggested in the XSL thread, some of the ruby properties should be
> reconsidered:
> 'ruby-align' is a combination of several largely orthogonal parts, and
> consequently should be broken up into several properties that handle
> alignment, edge handling and spacing. See also
> http://www.w3.org/Style/XSL/Group/FO/wiki/Ruby#Treat_CSS3_.22ruby-align.22_As_Shorthand.3F
> Furthermore, properties for character spacing and -transformation (narrow
> Katakana, changing small subscript Kana to standard-size for better
> legibility) are not ruby-specific and would IMHO better be handled in a
> separate general text module. Character spacing also needs to address how to
> handle non-Kanji/Kana characters.
> As everybody seems to agree, Bopomofo/Zhuyin-Fuhao is right out and will
> stay so until vertical text is properly supported by UAs.
> Regards,
> - Roland Steiner
> 2010/3/11 MURAKAMI Shinyu <murakami@antenna.co.jp>
> > Suzumizaki-Kimikata <szmml@h12u.com> wrote on 2010/03/11 9:30:11
> > > I think nesting ruby-element causes logically unsuitable.
> > >
> > > Ruby-text(<rt>) will always annotate ruby-base even the rt is
> > > second one, and never annotate the pair of ruby-base and the other
> > > ruby-text.
> > >
> > > Correct:
> > > Ruby-base is annotated by ruby-text-1, and
> > > Ruby-base is annotated by ruby-text-2.
> > >
> > > At least logically Wrong:
> > > Ruby-base is annotated by ruby-text-1, and
> > > the pair of ruby-base and ruby-text-1 is annotated by rt-2.
> >
> > I think that is not always true. Sometimes ruby nesting is logical.
> > For example, when the ruby-base is kanji, ruby-text-1 is its reading
> > (it's normal Japanese ruby usage), and ruby-text-2 is English word,
> > the pair of ruby-base and ruby-text-1, Japanese word, is annotated
> > by ruby-text-2, English word. See the following markup:
> >
> >  <ruby class="with-English-translation">
> >     <ruby>東<rt>とう</rt>南<rt>なん</rt></ruby>
> >     <rt>southeast</rt>
> >  </ruby>
> >
> > Seems logical markup, no?
> >
> > I admit the XHTML1.1 complex ruby may be more suitable for other cases,
> > for example Japanese reading and Chinese reading for Chinese person name,
> > in such case XHTML1.1 complex ruby will be better than ruby nesting.
> > But I'm not sure it is really important for HTML5 users.
> >
> > --
> > 村上 真雄 (MURAKAMI Shinyu)
> > http://twitter.com/MurakamiShinyu
> > Antenna House Formatter:
> > http://www.antenna.co.jp/AHF/
> > http://www.antennahouse.com
> >
> >
> >
Received on Sunday, 14 March 2010 11:03:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:31 UTC