- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 23 Feb 2012 12:29:00 +0100
- To: Roland Steiner <rolandsteiner@google.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Koji Ishii <kojiishi@gluesoft.co.jp>, fantasai <fantasai.lists@inkedblade.net>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Roland Steiner, Thu, 23 Feb 2012 13:26:57 +0900: > On Thu, Feb 23, 2012 at 12:51, Leif Halvard Silli wrote: >> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1348 > > I just opened this on IE 9.0.8112: > > Your demo does NOT show that IE9 handles row-major ruby. In fact, you > only have a single base in your "row-major" example! The difference > between IE and WebKit is that IE renders all the following "orphaned" > ruby texts on that single base, while WebKit assumes empty bases for > every such text. Hm. OK. You are right about that. I stand corrected. So we have zero browsers that support ruby display when using row-major code. > Your demo also does NOT show that you can use <rtc> in IE9 - the ruby > texts render next to the base rather than above it, which makes me > strongly believe <rtc> is handled as just another unknown element. Indeed. I meant nothing else: It is treated as an unknown element. But the most important thing is that IE does not auto-close. That's a pretty important detail when the claim is that HTML5's spec implements what IE does. Fact is that IE has never auto-closed anything *except* <ruby>, when it is placed inside <ruby>. > The contained <rt>'s, not being direct children of <ruby> anymore, > merely cause the text to be rendered in a smaller font, but still as > base (!). I see where they are placed. The important point, to me, was that IE does not auto-close the <rtc> — in contrast to what HTML5 says and in contrast to what Firefox and Webkit do. Hence one can use CSS to get it to display correctly. As a temporary measure, authors may be able to use use inline-table display: Such back-up CSS is much simpler with row-major coding style than it is with column-major coding style. But it does require that the UA does not close the <rtc>. >>> On Thu, Feb 23, 2012 at 11:42, Leif Halvard Silli wrote: >> Having outlined the differences between Webkit and IE [1], I cannot see >> that there is any win of having column-major conforming when we agree >> that the way forward is row-major. The only 'column-major subset' that >> should be conforming, is a ruby element with a single base plus a >> single text. > > The fact is that the current IE and WebKit implementations are both > column-major and there is a fair amount of web pages with such > content. > > Now, I don't want to argue that we necessarily should keep > column-major going forward. But any proposal should (and very The idea I put forward was only that column-mayor *authoring* should be non-conforming. But I am not against that they continue to render multi-column-major the way they do. The way IE and Webkit currently work, is compatible with the XHTML RUby module's version of 'simple ruby' - a single <rb> and a single <rt> per each <ruby>. And hopefully most ruby out there are such single-column-major ruby? If authors have looked at what XHTML allows, then one should thing: yes. >> In fact, this, >> >> <ruby>A<rt>a</ruby><ruby>B<rt>c</ruby><ruby>C<rt>c</ruby> >> >> is semantically equal to this: >> >> <ruby>A<rt>a</rt>B<rt>b</rt>C<rt>c</rt></ruby> > > I don't see these as semantically equivalent. To me the first is a > sequence of mono rubies, the second a single jukugo ruby. Firstly: According to fantasai's blog post, "the fundamental issue that distinguishing this [jukugo] from mono ruby is entirely stylistic". http://fantasai.inkedblade.net/weblog/2011/ruby/ Hence, *semantically* — that is: to the user [for instance a user that listens to it via a screen reader or searches for text strings via find-in-page] — the two are equivalent. Which means: They are equally difficult, for the user, to handle. [Of course, I agree that, with the first example, then there is a chance that UAs and AT becomes more advanced, and start to present things — to screenreader users and find-in-place tools — the way it *looks* rather than the the way it is coded. In that, hypothetical, case, then the former has an important advantage, to the user.] Secondly: Since it is only a stylistic issue, then *do* Webkit or Firefox actually render the latter example in jukugo *style*? Doesn't look like so, to me — but note that I had not time to do a thorough check before posting this reply. -- Leif Halvard Silli
Received on Thursday, 23 February 2012 11:29:36 UTC