Re: HTML5 and ruby

On 1/18/2012 1:27 PM, Leif Halvard Silli wrote:
> So, you say that a compound jukugo needs to be kept together as a 
> compound. 

Yes.

> And that that compound wrapper is <ruby>. 

Not exactly. It's not a wrapper for compounds in general. It is a 
construct for ruby and its use (a single <ruby> element with two pairs 
vs. two successive <ruby> elements with a pair each) could have an 
influence on the display.

> My claim, however, is that that is not enough: The <rt> between each 
> <rb> splits the compound up, preventing e.g. spellcheckers from 
> recognizing the compound as a compound. 

Clearly, spell-checking, just like any other text processing of an HTML 
document, needs to interpret the markup. Ideally, the spell-checking of 
"<i>un</i>fortunate" should not complain that "un" is not a word. I 
don't see that each <rt> splits the compound any more that the <i> 
splits "unfortunate".


> You see, the underlying claim of my question is that it
> doesn't matter whether you write
>
> 1.<ruby><rb>東</rb><rt>とう</rt><rb>京</rb><rt>きょう</rt></ruby>,
> 2.<ruby>東<rt>とう</rt>京<rt>きょう</rt></ruby>  or
> 3.<ruby><rb>東</rb><rt>とう</rt></ruby><ruby><rb>京</rb><rt>きょう
> </rt></ruby>

I understand that you don't want to treat the three forms as distinct.

I am pointing out that it seems natural to assign different 
interpretations to 1&2 on the one hand and 3 on the other, mostly for 
the purpose of constraining the possible renderings (jukugo on one hand, 
just adjacent "ordinary" ruby on the other).

Without a difference of interpretation, then one needs some other way of 
indicating that the two ruby in 3. form a group for jukugo treatment.  I 
was under the impression it would be easier to assign meaning to 
constructs made of the existing HTML elements, rather than request the 
addition of new elements.

Of course, one could always invent a CSS property that is the functional 
equivalent of a group id attribute, which in turn is the functional 
equivalent of a container element. Besides being intuitively awkward, it 
would also be painful in practice: some publishing workflows involve the 
mechanical injection of ruby and are much easier to implement if that 
does not involve CSS processing.

As for the underline, I did not invent it. The current draft makes 
<u>a</u><u>bc</c> render differently than <u>abc</u> when 
text-decoration='edges'.

Finally, it has long been the case that "<span>a</span><span>bc</span> 
can render differently than <span>abc</span>, e.g. when there is a 
visible border. If it there is a difference for <u> and <span>, I don't 
quite understand the value of insisting on no difference for <ruby>.

Eric.

Received on Wednesday, 18 January 2012 23:19:59 UTC