[whatwg] My case for Ruby-elements
bhawkeslewis at googlemail.com
Tue Aug 14 11:23:59 PDT 2007
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
> 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:
and our current user agent accessibility guidelines:
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.
More information about the whatwg