[Bug 10830] i18n comment : Please add support for rb

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10830

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no

--- Comment #46 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-09-09 00:32:00 UTC ---
The editor asked for permission to reconsider this bug before it goes through
the CP mill. 

http://www.w3.org/mid/DE1740C7-38FF-4D3D-B768-C9712F089B50@apple.com

And in that regard, I wanted to add some points for his consideration:

(1) Legacy IE support for <rb> is easy to add via the well known 'HTML5 shiv'
hack:

    <script>document.createElement("rb")</script>

    The <rb> is in this regard no different from any other element 
    that is unknown to IE. In fact, even if <rb> would *not* be added
    to HTML5, it would still be correct for browsers to treat it as an
    unknown element:

     http://www.w3.org/TR/2010/WD-html5-20100624/obsolete.html#dom-ul-type 

    ]]  
       The bgsound, isindex, multicol, nextid, rb, and spacer elements 
       must use the HTMLUnknownElement interface.
   [[

   Firefox has followed this route for the <spacer> element:

   http://hsivonen.iki.fi/spacer/

   Thus it would be correct, per HTML - even if <rb> is not added to HTML5 as a
   legal element - to ask HTML5 library developers, such as Remy Sharp
   (http://code.google.com/p/html5shiv/) to add support for <rb>. 

   Also, until  HTML5 eventually adds support for <rb>, it would be entirely
   correct of browsers to  let the markup <ruby><rb>a<rt>b</ruby> result
   in the following DOM: <ruby><rb>a<rt>b</rt></rb></ruby>. (Fingers
   crossed.) If I am wrong in that assumption - that they should create the 
   correct DOM regardless, then I can't see that there would be any technical
    reason to not add <rb>.


(2) That <rb> isn't very much used as a CSS selector, can be considered an 
     advantage - it means that no one would "break the Web" by enabling 
     support for <rb>.


(3) A use case for <rb>: Rather than styling <rb> itself - as the editor asked
     for examples of, it seems more meaningful to do things like this:

     rb:hover+rt,rb:hover+rp+rt{color:red;/*highlight*/}

     Such styling can be used to show (if <rt> is hidden) or highlight (to
identify 
     the <rt> ths is connected with the <rb>) theruby term when the 
     user hover above the ruby base sign.

(4) The Wasting authors time argument: 

     Of course, it would be technically possible to use <span> for this
instead. 
     Like it would be tecnically possible to use <span> instead of <dt>.
     However,  it seems to make more sense to the <rb>: AUthors would
     then know its purpose - while a <span> could be used for many 
     functions - thus a <span> would not make immediate sense for 
     someone inspecting the code. Remember as well that code might
     be shuffled around: I could store the content of a definition list
     "outside the Web", for reuse in actual <dl> listes - and in that case
     it would have been quite annoying to have to decide which 
     inline element to use for <dt> - just as it would be annoying to have 
     to decide which inline element to use instead of <rb>.

     So, while it *perhaps* would be a waste of time to *require* <rb>,
     it seems also a wast of authors time to force them to pick a 
     random inline element. Such a thing wouild also create a lot more
     "div-it-is" or "span-it-is" (overuse of span/div) looking code,
     in contrast to allowing a dedicated element that everyone know
     the purpose of.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 9 September 2011 00:32:08 UTC