Re: Memo from ruby disucssion with Roland

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