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

Hello Makoto,

[The reason this didn't go out yesterday was some minor system problem 
around here.]

On 2012/02/22 15:51, MURATA Makoto wrote:
> 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

I agree that good layout of double-sided ruby is difficult, but there 
are quite a few other layout issues that are difficult to automate, too. 
Just because really good layout is difficult shouldn't mean that we 
don't create markup. As far as I understand, markup and layout (i.e. 
styling) are separate issues when it comes to W3C technology.


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

That's a very good thing.

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

That's one way of seeing things, and it's not totally wrong. But there 
are two problems here:

1) The range of annotations is extremely wide. Ruby are very local and 
small. Other annotations may be long and far away (e.g. at the end of a 
book). It isn't sure at all that the same markup is well suited for all 
these cases. Would you think RDF is a good solution for ruby?

2) When we worked on the Ruby Annotation REC, Steven Pemberton proposed 
that we should generalize the concept (he wasn't speaking about 
annotations in general, but glosses). Looking at how far XHTML 2.0 went, 
I'm glad we didn't. If <annotation> (or something similar) would already 
exist, maybe we'd never had any need to define <ruby> in the first 
place. But currently, <annotation> doesn't exist.

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

Interesting link, thanks.

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

What is there in terms of markup (not layout!) that the ruby proposals 
currently floating around wouldn't cover?

Regards,    Martin.

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

Received on Friday, 24 February 2012 03:18:46 UTC