Re: Ruby in HTML5

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
>
>
>