[whatwg] My case for Ruby-elements

[Benjamin Hawkes-Lewis]

Brian Smith wrote:
> Michel Fortin wrote:
>> Le 2007-08-13 à 12:25, Krištof Želechovski a écrit :
>> 
>>> The text is not interlaced but it is vertically synchronized in
>>> order that you can know which passage in your language
>>> corresponds to which passage in the other language..
>> I don't think Ruby markup to be appropriate here. But I can see how
>> reading effectively such a document could be difficult on a screen
>> reader.
> 
> Like Michel said, Ruby markup isn't appropriate for this use case.
> Ruby text is designed to be used to provide pronunciation and
> disambiguation cues for logographic languages, especially Japanese
> and Chinese. If you are not dealing with a logographic language, then
> generally Ruby annotations are not for you.
> 
> Phoneme-by-phoneme or word-for-word transliterations (e.g. Latin
> transliteration of Thai words) might also be an appropriate use for
> Ruby text. But, translations and transliterations that are not
> word-for-word are not what Ruby markup is designed for.

The Ruby specification does not say that Ruby annotations are only for 
"pronunciation and disambiguation cues for logographic languages". The 
spec merely presents that as a /typical/ use: "'Ruby' are short runs of 
text alongside the base text, typically used in East Asian documents to 
indicate pronunciation or to provide a short annotation." Or again: 
"Ruby is the term used for a run of text that is associated with another 
run of text, referred to as the base text. Ruby text is used to provide 
a short annotation of the associated base text. It is most often used to 
provide a reading (pronunciation guide)."

I strongly oppose HTML5 dropping or altering semantics of existing 
elements (ACRONYM, SMALL, etc.), but IMHO the use-case that motivated 
bringing a feature into (X)HTML should not be used to prohibit new uses 
/unless/ the new uses theoretically conflict with the old. Saying that 
"Feature X was designed for Y" merely restates its original purpose. It 
doesn't explain why it using it for Z conflicts with using it for Y.

Having said that, I'm not terribly comfortable with the suggested use of 
Ruby. I think that's because:

1. I suspect we're trying to paper over the big holes in HTML's crude 
hypertext and numbering implementations.

2. I'm not sure whether there are any user agent conformance criteria in 
place that would guarantee that ideal user agents would allow users to 
read such text easily. (For example, allowing aural browsers to ignore 
the Strong numbers and translation hints, if the user chose. Or 
retrieving the annotations for a particular segment of text.) But make 
up your own mind from the discussion of non-visual use of Ruby in the spec:

http://www.w3.org/TR/ruby/#non-visual

and our current user agent accessibility guidelines:

http://www.w3.org/TR/WAI-USERAGENT/

The current Ruby spec suggests using CLASS to disambiguate different 
uses of Ruby. I'd prefer a fixed set of TYPEs for which user agents 
would be expected to actually implement selection features.

3. I suspect that such markup would be (for now) practically unusable 
given that current user agents are far from ideal implementations of 
Ruby or the User Agent Accessibility Guidelines.

--
Benjamin Hawkes-Lewis