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

Arguments against HTML double-sided ruby (was: Re: Memo from ruby disucssion with Roland)

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Wed, 22 Feb 2012 15:51:03 +0900
Message-ID: <CALvn5EDjHzU=VOhMCqaV7rraZ_6jxg5E89KqSrYOp7G6xEnHjA@mail.gmail.com>
To: "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Should HTML (and CSS) support double-sided ruby?  I think that
more discussions are needed before we discuss about the design
of HTML markup.

First, as I wrote in my mail "Desiderata for automatic layout of
double-sided ruby", an important example of double-sided ruby
makes automatic formatting and markup design (ruby for ruby,
and right-left-swapping) very difficult.  What is the scope of
double-sided ruby?

http://lists.w3.org/Archives/Public/public-i18n-cjk/2012JanMar/0067.html

Second, annotations have become an important topic for the WWW
and e-book.  NISO, W3C, and IDPF are very much interested in
allowing people to create annotations for their own documents or
other documents.  What is the relationship between ruby and
annotations?  Here is one possibility: ruby is just one way for
formatting annotations, and we need a generalized mechanism for
annotation formatting.  HTML ruby is just a short cut for simple
and common cases, which are not double-sided.  Further
generalizations of HTML ruby are questionable.

http://www.niso.org/topics/ccm/e-book_annotation/
http://www.w3.org/community/openannotation/
http://code.google.com/p/epub-revision/wiki/Annotations

I am not convinced why a specialized solution for double-sided
ruby is needed.  (It is not only me who argues against HTML
double-sided ruby in public-html-ig-jp@w3.org).  If there is a
consensus to introduce such a solution, I would like to request
that my favorite books (the collection from Kodan-sha) be covered.

Regards,
Makoto

2012/2/22 Roland Steiner <rolandsteiner@google.com>:
> On Wed, Feb 22, 2012 at 14:44, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
> wrote:
>>
>> Hello Roland,
>>
>> On 2012/02/22 13:37, Roland Steiner wrote:
>>>
>>> Sorry for chiming in late to this thread!
>>>
>>> Koji summed up our discussion pretty well, I think. There's just one
>>> thing
>>> I wanted to add to the reasoning of the 'for' approach for clarification:
>>>
>>> With 'rspan' or<rtc>, there is no semantic link from the base to the
>>> text(s). For example:
>>>
>>> <ruby><rb>東<rb>京<rtc>とうきょう</ruby>
>>>
>>> and similar with 'rspan' - in this case, even if you add, remove or edit
>>> the bases dynamically, the ruby text will always be 'とうきょう'. This is what
>>> I
>>> wanted to address with the 'for' attribute: the text would only be
>>> rendered
>>> if the bases it refers are present within the same ruby, and rendered in
>>> the order it refers them. E.g.
>>>
>>> <ruby><rb id=T>東<rb id=K>京<rt for="T K">とうきょう</ruby>
>>>
>>> In this case, 'とうきょう' should only be rendered if there are the bases 'T'
>>> and 'K', consecutively, in that order. If, for example, the base for '東'
>>> is
>>> removed, the text would no longer be applicable, and thus not rendered.
>>> Neither would it be rendered if 'T' or 'K' are not the id of a<rb>
>>>  within
>>> the same ruby.
>>
>>
>> What exactly would such a functionality be good for? I don't really see
>> the average JavaScript hacker to change the text underlying some ruby. I
>> also don't see the point of having the ruby text 「とうきょう」in there waiting for
>> the moment somebody inserts a base with identifiers T and K again.
>
>
> Mainly to decouple bases and text - e.g., to allow for fall-back:
>
>     <ruby><rb id=T>東<rb id=K>京<rp> (<rt for=T>とう<rt for=K>きょう<rp> ) </ruby>
>
> and to provide layout flexibility, e.g., when switching to bopomofo ruby:
> render <rt> that applies to a single base to the right, but text that
> stretches several bases below (or some such). However, this notation as is
> would play havoc on fallback to current HTML5 ruby, so I'm not entirely
> convinced myself it's such a good idea.
>
> As for changing the underlying ruby via JavaScript: whether or not it's
> common is not relevant from an implementation point of view, but that every
> possible configuration and operation is defined and handled correctly,
> including intermediate states that may happen during larger DOM
> manipulations (as in my example), or even nonsensical combinations.
>
>
> Cheers,
>
> - Roland



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
Received on Wednesday, 22 February 2012 06:51:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 February 2012 06:51:35 GMT