The HTML5 spec contains an <rtc> element (http://www.w3.org/TR/html5/text-level-semantics.html#the-rtc-element) as part of its ruby support. We currently allow <ruby>, <rt>, <rp>, and <rb> but not <rtc>.
Version: unspecified
Severity: normal
cscott | |
Jun 24 2014, 6:14 PM |
F14452: Screen_Shot_2014-07-01_at_3.51.38_PM.png | |
Nov 22 2014, 3:36 AM |
F14451: Screen_Shot_2014-07-01_at_3.55.11_PM.png | |
Nov 22 2014, 3:36 AM |
The HTML5 spec contains an <rtc> element (http://www.w3.org/TR/html5/text-level-semantics.html#the-rtc-element) as part of its ruby support. We currently allow <ruby>, <rt>, <rp>, and <rb> but not <rtc>.
Version: unspecified
Severity: normal
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T25932 Allow use of semantic HTML5 elements in wikitext | |||
Resolved | cscott | T69042 Allow HTML5 <rtc> tag (ruby support for East Asian typography) |
Change 141742 had a related patch set uploaded by Cscott:
Allow HTML5 <rtc> tag (ruby support for East Asian typography).
Hm. The W3C and WHATWG seem to disagree about the status of <rb> and <rtc>. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26187 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=26189
Both Firefox and Chrome seems to follow the WHATWG, not the W3C. That is, they parse:
<ruby><rb>foo<rp>bar</ruby>
"incorrectly" as:
<ruby><rb>foo<rp>bar</rp></rb></ruby></div>
According to the W3C, the <rb> tag should be closed before the <rp>.
So... I'm not sure it's a good idea to add the <rtc> tag at this time. The right thing to do might be to *remove* the <rb> tag, to make us match WHATWG's spec (which lists <rb> explicitly as "non-conforming" in http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#non-conforming-features ).
OK, got confirmation (mostly via twitter (!)) that webkit and gecko are on-board with the W3C's rb/rtc changes. See:
https://twitter.com/cscottnet/status/481534354842484736
https://bugs.webkit.org/show_bug.cgi?id=131175
https://bugzilla.mozilla.org/show_bug.cgi?id=664104
So I guess we can go ahead with the patch in https://gerrit.wikimedia.org/r/141742
Once this lands in core, we'll need corresponding patches for Parsoid and the domino and html5 packages (@robinberjon has offered to help with the latter two).
Well, "agrees" might be too strong a term: https://bugzilla.mozilla.org/show_bug.cgi?id=664104#c35
Change 142455 had a related patch set uploaded by Cscott:
Allow HTML5 <rtc> tag (ruby support for East Asian typography).
Created attachment 15809
Current rendering of ruby samples in IE 11 & dev preview with patch
Just for reference, here's a screenshot of the ruby examples in the parserTests.txt file rendered on a wiki (with the patch on) in IE 11 (Windows 8.1 Update) and IE Developer Preview.
The "double-sided ruby" with the 'San Francisco' translation is the one using the new <rtc> element, and as expected renders the second ruby line not as a ruby line since IE 11 doesn't know about <rtc>.
The others all render as expected, which is not surprising as the HTML ruby spec is apparently based on IE's implementation. ;)
Attached:
Created attachment 15810
Screenshot of ruby examples in current Safari 7.0.5
For reference again, the ruby samples from the parser test case copied into a wiki page (with the patch) and rendered in Safari. Current Chrome appears about the same, including current Canary builds.
Note that in addition to the <rtc> not being supported yet and rendering outside the ruby area (as expected), the "inline" and jukugo forms do *not* render correctly in Safari/WebKit or Chrome/Blink -- the annotations "spill over" and align incorrectly.
(Also note that latest FirefoxNightly parses the ruby elements but doesn't *render* them as anything but plain text yet.)
Attached:
Change 141742 merged by Brion VIBBER:
Allow HTML5 <rtc> tag (ruby support for East Asian typography).
Change 144745 had a related patch set uploaded by Cscott:
Add <rtc> tag support to RELEASE-NOTES-1.24.
Change 142455 merged by jenkins-bot:
Allow HTML5 <rtc> tag (ruby support for East Asian typography).