W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 30 Nov 2011 15:28:06 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RVm4s-0002a8-Hn@jessica.w3.org>

Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu> changed:

           What    |Removed                     |Added
                 CC|                            |kennyluck@csail.mit.edu

--- Comment #72 from Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu> 2011-11-30 15:27:56 UTC ---
(In reply to comment #69)
> Please share the information about how it is 'potentially harmful'.

I agree this is critical information and I am specifically curious about the
cost of making an element that used to be a HTMLUnkownElement to HTMLElement
and other harms to authors that I am unaware of at the moment. 

(In reply to comment #63)
> The opinion I have stated in this bug is in comment 3. The data presented
> suggests that authors generally don't style <rb>, however, so I'm not convinced
> it needs to be added to the language.

I am not sure what you mean by "add to the language". If you mean new
auto-closing/parsing behavior then I might agree with you and that's the
subject of bug 13113. But from the educational perspective, removing <rb> is
already not backward compatible (MSDN and the like). Keep telling people "don't
look at those specs produced in the dark era" and explaining the history of the
specs are not realistic. I just ran into a speaker today who talked about about
<ruby> and reference the HTML5 spec but yet used <rb>. I guess they might have
been affected by the EPUB work and someone might want to stop them (though
that's not me because I support <rb>).

== Authoring Difficulties ==

Again from author's point of view, there are many pair-like constructs in HTML

* <dt> <dd> pair in <dl>
* <caption> <tbody> pair in <table>
* <img> <figcaption> pair in <figure>
* <summary> (whatever) pair in <details>

I feel uneasy to have to create the pair-like ruby-base/ruby-text association
implicitly by using the parent <ruby> element. It's simply an unusual practice
in the HTML language. (This recognition problem might or might not just apply
to me given data in Comment 42 and Comment 43)

Also, I had to check the spec to see, for <ruby>AB<rt>C</rt></ruby>, C is the
ruby-text for AB instead of just B (bear with me, for Chinese and Japanese,
that explanation might work). Normal people won't read the spec.

(In reply to comment #70)
> > > Koji Ishii and I believe that the rb tag is widely implemented.
> > 
> > You are wrong. Browsers all treat <rb> the same as <xxx>. [ snip ]
> How UAs treat <rb> an <xxx> - and ruby markup in general, can be seen on this
> testcase:
>  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1264

Could we please not make the "widely implemented" argument again before we
define what "implement"  or "parsing" means here?

> Results:
> (3)  Firefox doesn't apply any styling to <ruby> markup, **but** it does apply
> ruby *parsing*: if you forget to close the <rb> element (or if you use <span>
> instead and forget to close it) then the element will be closed once the parser
> sees the <rp> or <rt> element. Firefox seems to apply ruby parsing since at
> least version 3.
> (4) Webkit (Safari/Chrome) apply ruby parsing, like Firefox does. In addition
> it applies ruby CSS.

If you modify your example to something like <ruby><rb>A<rt>B<rb>C<rt>D</ruby>
then the "ruby parsing" won't work in FF8 and Safari 5.1. Although if I
understand correctly it might work again because of bug 12935. 

Conclusion: my main argument here is language consistency, although I am more
of a XHTML person (whatever that means) and I don't omit tags often so I don't
know if my feeling applies to general authors.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 30 November 2011 15:28:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:22 UTC