Re: HTML5 and ruby

Eric Muller, Wed, 18 Jan 2012 15:19:31 -0800:
> On 1/18/2012 1:27 PM, Leif Halvard Silli wrote:

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

Though I understand that a spell checker tool could be made to handle 
the fact that an <rt/> is inserted into the word, these two things that 
you mention seem rather different: In the <rt/> case, it is an element 
in the middle of the word, whereas in the '<i>un</i>fortunate' case, 
the correct thing would be to ignore that there is a <i>. A screen 
reader like NVDA has no problems recognizing "<i>un</i>fortunate" as a 
single word.

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

So then you have the rendering of the ruby text in mind. I understand 
that argument. My focus is perception of the ruby base/bases.

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

I do try to work with the 'existing HTML' as well: Trying to consider 
how screen readers and spell checkers actually interpret mark-up is a 
perspective that is focused on 'existing HTML'. I am not aware of any 
other structure in HTML where an element - without the use of CSS - can 
suddenly pop up inside the middle of the word. However, I admit that it 
might be that I, as hinted by Martin, have calculated the problem with 
that wrongly.

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

Do you have a link?

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

Did you by 'no difference for <ruby>' also mean 'no difference for 
<rb>'?

Some screenreaders, at least VoiceOver, do get problems if you 'split' 
up a word using inline elements, causing that the word is read as 
several words instead of as a single word. Others, like NVDA, do not 
have that problem. I think that the logical thing would if it does not 
create problems. That said: The CSS display property impacts on what is 
perceived as a word as well. For instance, for this example:

   <un style='display:inline-block'>un</u>fortunate

then even NVDA will read it as two words. NVDA will, btw, not let 
elements with display:none affect the reading. So this:

   un<un style='display:none'>super</u>fortunate

would be read as 'unfortunate' by NVDA.
-- 
Leif Halvard Silli

Received on Thursday, 19 January 2012 06:44:49 UTC