W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > October to December 2010

RE: <rp> fallback in complex ruby.

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Wed, 8 Dec 2010 02:22:23 -0500
To: 塩澤 元 (Shiozawa, Hajime) <hajime.shiozawa@gmail.com>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AA8B1B951@MAILR001.mail.lan>
This is a very interesting topic to me. I was also wondering what is the ideal solution for the fallback in HTML5 ruby.

When complex ruby was designed in late 90's, the most major browser was Netscape 4, and we had no idea if NS4 would ever support ruby. The complex ruby was designed to fallback gracefully for browsers that has no knowledge of ruby.

But today, I think we can think two different types of the "fallback"; one is where a browser has no knowledge of ruby, the other is where a browser does not prefer rendering ruby because of screen real estate or user preferences.

I think the former is less important today. If this assumption is correct, I think we can develop a new type of the "fallback"; that is, a browser knows about ruby, but just doesn't want to render above the base characters. In this case, a browser could display this markup:

<ruby>
  漢<rt>かん</rt>
  字<rt>じ</rt>
</ruby>

as:

  漢字(かんじ)

using its own intelligence.

I have to admit that I'm not very familiar with how strict HTML5/CSS Ruby allows or prohibits such kind of rendering, but what I'm saying is that, we should forget about the true "fallback" when a browser has no knowledge of ruby, and start thinking about graceful "inline" display of ruby. These two, as far as I understand, are considered to be the same today, but making these two separate ideas may be able to resolve the situation.

What do you think?


Regards,
Koji

-----Original Message-----
From: public-i18n-cjk-request@w3.org [mailto:public-i18n-cjk-request@w3.org] On Behalf Of 塩澤 元 (Shiozawa, Hajime)
Sent: Tuesday, December 07, 2010 2:54 PM
To: public-i18n-cjk@w3.org
Subject: <rp> fallback in complex ruby.

I'm considering about the fallback using <rp> in complex ruby.

*Markup
<ruby>
  <rbc><rb>漢</rb><rb>字</rb></rbc>
  <rp>(</rp>
    <rtc><rt>かん</rt><rt>じ</rt></rtc>
  <rp>)</rp>
</ruby>

In this case, the UA that doesn't support complex ruby would render like below.

*Rendering
  漢字(かんじ)

If <ruby> has two <rtc>,

*Markup
<ruby>
  <rbc><rb>漢</rb><rb>字</rb></rbc>
  <rp>(</rp><rtc><rt>かん</rt><rt>じ</rt></rtc><rp>)</rp>
  <rp>(</rp><rtc><rt rbspan='2'>Kanji</rt></rtc><rp>)</rp>
</ruby>

*Rendering
 漢字(かんじ)(Kanji)

In HTML5, <rp> is used like below markup.

*Markup
<ruby>
  漢<rp>(</rp><rt>かん</rt><rp>)</rp>
  字<rp>(</rp><rt>じ</rt><rp>)</rp>
</ruby>

*Rendering
  漢(かん)字(じ)

Acutually this rendering isn't easy to read, becuase the pronunciation is divided. (of course it is easy to read if an UA supports ruby!)
'漢字' is considered as a compound word (jukugo), so I think the prounountiation should not be divided. (So rtc and rbc markup and styling is very strong.)


The specificaiton of XHTML Ruby say that <rp> element is not avaliable in the case of complex ruby markup.
There are two reasons [1].

"First, the rp element is only a fallback mechanism, and it was considered that this is much more important for the more frequent simple case."
"Second, for the more complex cases, it is difficult to come up with a reasonable fallback display, and constructing markup for such cases can be even more difficult if not impossible."

Considering digital publising technology based XML and CSS like epub, I think it is important to consider the divistiy of UAs (from very high book viewer to very simple web browser on mobile phones.) I think that the markup that I gave would be a pretty reasonable.

Do you have any ideas or comments for this suggestions?


[1]: http://www.w3.org/TR/ruby/#complex



Regards,
Hajime.



--
# 青山学院大学大学院
# 理工学研究科  知能情報コース
# 塩澤 元 (Shiozawa, Hajime)
# mail: hajime.shiozawa@gmail.com

Received on Wednesday, 8 December 2010 07:25:40 UTC

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