W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2010

[whatwg] rp is a styling tag and has no semantic function

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 9 Mar 2010 01:26:13 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1003090118250.21376@ps20323.dreamhostps.com>
On Wed, 28 Oct 2009, Nikita Popov wrote:
>
> In the spec the use of the rp-tag is shown like this:
> 
> <ruby>
> ??? <rp>(</rp><rt>??????</rt><rp>)</rp>
> ??? <rp>(</rp><rt>???</rt><rp>)</rp>
> </ruby>
> 
> What semantic function has the rp-tag? No. It is only styling for browsers not
> supporting ruby-text.
> So I think this element musn't be in the HTML5 spec. You can add the brackets
> before and after the ruby text using CSS pseudoclasses (:after, :before).

What about when the legacy browser doesn't support CSS?


On Fri, 30 Oct 2009, Nikita Popov wrote:
>
> How should a screen-reader actually handle ruby annotations? In this 
> case
>
> <ruby>
> ?? <rt> ???? </rt>
> ?? <rt> ???? </rt>
> </ruby>
>
> it would be quite strange if a screen-reader read the annotations, 
> because they have the same content as the ruby base text. (I hope this 
> is correct. I don't know the Japanese language, but I understood it as 
> ?? beeing same as ???? only in a different "way" of writing.) So the 
> reader must not read the annotation.

Exactly how ruby annotations are rendered is UA-defined.


> In an example i got from an older W3C spec, it's different:
> 
> <ruby>
>   <rbc>
>     <rb>10</rb>
>     <rb>31</rb>
>     <rb>2002</rb>
>   </rbc>
>   <rtc>
>     <rt>Month</rt>
>     <rt>Day</rt>
>     <rt>Year</rt>
>   </rtc>
>   <rtc>
>     <rt rbspan="3">Expiration Date</rt>
>   </rtc>
> </ruby>
> 
> As this markup isn't used anymore with HTML5, here's how it would be
> (dropping the "expiration date"):
>
> <ruby>
> 10 <rt>Month</rt>
> 31 <rt>Day</rt>
> 2002 <rt>Year</rt>
> </ruby>
>
> This one now should be read out by the screen-reader. Otherwise the
> meaning of the numbers may be not as clear.
> 
> (Or is the date-example out-of-date and ruby shouldn't be used there?)

In both cases, I would personally expect a speech UA to indicate to the 
user that annotations are available, without immediately rendering them. 
However, I'm no expert on the matter!


On Fri, 30 Oct 2009, Futomi Hatano wrote:
> 
> More correctly, screen-readers should read only the contents of <rt> rather than the base text.
> That is, screen-readers are expected to read it as "ka-n-ji" from <rt>s.
>
> [quoting the date example above]
> 
> I think that <ruby> of HTML5 is not appropriate for the case.
> According to the HTML5 spec, <ruby> is "primarily used in East Asian typography as a guide for pronunciation or to include other annotations".
> I think that this element was not designed for the case you mentioned.
> "Ruby Annotation module for XHTML 1.1" can be used for a broad range of objectives.
> But <ruby> of HTML5 is limited, I think.

As far as I can tell the problem for speech browsers exists the same in 
both variants of Ruby markup.


On Fri, 30 Oct 2009, Nikita Popov wrote:
>
> I am not sure whether it is as easy. Please consider this one:
> <ruby>
> char <rt>pron 1</rt>
> another char <rt>pron 2 pron 3</rt>
> and some other text without a ruby annotation.
> </ruby>
> If a screen-reader now only would read the ruby-annotations, it would
> sound like this: "pron 1 pron 2 pron 3" and the rest of the text
> wouldn't be read.

On Sat, 31 Oct 2009, Futomi Hatano wrote:
> 
> The text without a ruby annotation should not be in <ruby>.
> It should be marked up like this:
> 
> <ruby>
> char <rt>pron 1</rt>
> another char <rt>pron 2 pron 3</rt>
> </ruby>
> and some other text without a ruby annotation.

On Sat, 31 Oct 2009, Nikita Popov wrote:
>
> Yes, that's right. But there are always people not as strict. I think
> some ninety-nine percent of websites aren't valid an even less semantic.
> HTML5 mustn't be planed only for the exemplary developers but for the
> standard-user, too.

On Sun, 1 Nov 2009, Futomi Hatano wrote:
> 
> Do you think that HTML5 should support bad markups? I don't think so.

Supporting "bad markups" seems to be a losing proposition, since we'd 
never be able to rely on any of the markup to determine how to render it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 8 March 2010 17:26:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC