Re: Arguments against HTML double-sided ruby (was: Re: Memo from ruby disucssion with Roland)

MURATA Makoto, Fri, 24 Feb 2012 18:57:49 +0900:

>>> Should HTML (and CSS) support double-sided ruby?  I think that
>>> more discussions are needed before we discuss about the design
>>> of HTML markup.

First you said 'HTML (and CSS)'. Then you said 'the design of HTML 
*markup*'. 

Which made me think: Perhaps CSS should support double sided ruby even 
if mark-up only supports single sided? And in that regard: What about 
the solution to nest <ruby> inside <ruby>?

Fantasai claims that it is a hack. A different way to say the same 
thing, would be be: Nested ruby does not count as "HTML support" ... 
or? At least not if we avoid defining the *presice* relationship 
between the second/nested ruby level and the first level, but  - 
instead - more treat the second ruby text as having a "stylistic" 
relationship to the the base of the outer ruby.

Because, the strongest argument in favor of - some form of - double 
ruby, seems to me to be single ruby itself. Namely: The author should 
not have to use drop even single ruby just because the text should look 
like double ruby! And it is for this reason that I think that the 
relationship between the ruby base and the second ruby line does not 
need to be so strong, clear and direct as the relationship between the 
base and the first ruby text and the. Which, in turn, makes me positive 
towards 'nested [single] ruby elements' as a solution to the problem.

More on this below.

>>> First, as I wrote in my mail "Desiderata for automatic layout of
>>> double-sided ruby", an important example of double-sided ruby
>>> makes automatic formatting and markup design (ruby for ruby,
>>> and right-left-swapping) very difficult.  What is the scope of
>>> double-sided ruby?
>>> http://lists.w3.org/Archives/Public/public-i18n-cjk/2012JanMar/0067.html

>> 
>> I agree that good layout of double-sided ruby is difficult, but there are
>> quite a few other layout issues that are difficult to automate, too. Just
>> because really good layout is difficult shouldn't mean that we don't create
>> markup. As far as I understand, markup and layout (i.e. styling) are
>> separate issues when it comes to W3C technology.
> 
> But should we introduce double-sided HTML ruby just because there are
> rare examples of double-sided ruby such that automatic layout is doable?
> Which one listed in http://www.w3.org/International/wiki/Rb#Real_Examples

> and which one in the Kodansha collection is in the scope?  I have seen
> no discussions about the scope so far.  I certainly know markup
> and styling are separate issues.

To both Martin and Makoto I would say: Precisely from mark-up point of 
view, the question about whether we should support it just because it 
is doable, is very important to answer.

Single sided ruby has a - more obvious - logic to it. As Martin earlier 
told:  When a text has [single-sided] ruby, then Japanese users expect 
the ruby text - not the ruby base - to be presented to them. But in 
case of double sided ruby, how would a user expect the presentation? 

Would users expect the second 'double' ruby text to be read first — and 
then the first 'single' ruby text? Or would users expect the first ruby 
text first — and then the second? In a way, for double ruby, the 
presentation becomes less 'smooth'. For single ruby, users - e.g. a 
screenreader users - do not even need to know that ruby is in use. But 
for double ruby, then the very content of the second ruby text, is 
likely to cause e.g. screenreader users to understand that there are 
two different ruby texts. 

In that regard, it is relevant that the first/upper/single ruby text 
tends to contain simply another way to represent the ruby base - such 
as 'one' and '1'. While the second/double ruby text tends to be a 
translation - either in the form of synonymous word in another language 
[such as French 'une' for 'one'] or a word definition.

Take for instance Fantasai's double ruby examples: 
http://fantasai.inkedblade.net/weblog/2011/ruby/#double

In each example, the first/single/top ruby text can be presented the 
way Martin described. While the second/double/bottom ruby, in English 
or with Latin text, becomes a translation/definition.

Which leads me to ask: While single-sided ruby has rather clear 
semantics - it is usually taken to mean 'another way to write the same 
thing', then perhaps the extra line of ruby text in double sided ruby 
can be seen as more of a styling issue than a mark-up issue? I say this 
because, the first ruby line looks to have different semantics than the 
second ruby line. 

Which, as told above, makes me wonder if nested ruby + CSS, actually is 
quite acceptable as a way of doing double ruby? 

In that regard, based on HTMl5's current model, then Fantasai in her 
blog post presented the following HTML5-model as a possibility, which 
she describes as a hack [I reordered the example to be row-major - but 
that is *yet another* problem, not *directly* related to this issue]: 

<ruby>
  <ruby>上手<rt>ず</rt><rt>じょう</rt></ruby>
  <rt>jou</rt><rt>zu</rt>
</ruby>

Note that in this variant of nested ruby, then the natural way to 
present the text to user becomes 'The second ruby text is presented 
first, and thereafter the first ruby text is presented.' Because, after 
all, the ruby text should be presented first - according to what Martin 
explained, and thus the 'outer' ruby text would be natural to present 
before the 'inner' ruby text. Or, to view it from another angle: The 
inner ruby element becomes a ruby base of the outer ruby element. I 
must admit, that to me, this makes some sense. So I am not so sure, 
anymore, that this is a hack. Because, after all, the *implicit* 
relationship between the first and the second ruby element, is quite 
strong and logical. [I am trying to analyze it from a markup semantic 
point of view - and not from a CSS point of view.]

Nevertheless, another and arguably simpler [to authors and simplistic 
parsers] form of the 'nested ruby' model, is also possible:

<ruby>上手<rt>ず</rt><rt>じょう</rt>
  <ruby><rt>jou</rt><rt>zu</rt></ruby>
</ruby>

In this latter model, the inner <ruby> is used like a <rtc> element. 
But, being a nested <ruby>, the implicit relationship of the first and 
the second ruby element, is weaker than it is in fantasai's example. 
Which seems defendable, when we consider what I said about the second 
ruby text above as having a more "stylistic" relationship to the ruby 
base. Also, in this model, the natural thing becomes to read the first 
ruby text first - something which I don't know whether is good or bad 
or even important, but it means that single and double ruby would be 
rendered more similar since the first ruby would always be read first - 
in both single-sided and double-sided ruby — which doesn't sound like a 
bad thing.

>>> What is the relationship between ruby and
>>> annotations?  Here is one possibility: ruby is just one way for
>>> formatting annotations, and we need a generalized mechanism for
>>> annotation formatting.
>> 
>> That's one way of seeing things, and it's not totally wrong. But there are
>> two problems here:
>> 
>> 1) The range of annotations is extremely wide. Ruby are very local and
>> small. Other annotations may be long and far away (e.g. at the end of a
>> book). It isn't sure at all that the same markup is well suited for all
>> these cases. Would you think RDF is a good solution for ruby?
> 
> There is nothing wrong in providing annotations for small text
> chunk and displaying them as ruby.  As for RDF, it may be
> a W3C's favorite choice, but I am not sure if others are committed
> to them for identifying text to be annotated.  IDPF might
> use EPUBCFI, http://idpf.org/epub/linking/cfi/epub-cfi.html


Here I would like to make the point I made above: If we agree that the 
first/upper ruby text line inside double ruby is equivalent to the ruby 
text line in single ruby, then it doesn't appear logical if, for each 
time one needs double ruby, the one choose another element than <ruby>: 
Such a thing would mean that e.g. screen reader users would not 
perceive double ruby as ruby at all. I think *that* is the strongest 
argument for - some form of - double ruby markup. So, we should make 
sure that, even for double ruby, then *at least* what the author 
intended as the *first/upper* ruby text, can be presented as such to 
the user.

>> 2) When we worked on the Ruby Annotation REC, Steven Pemberton 
>> proposed that
>> we should generalize the concept (he wasn't speaking about annotations in
>> general, but glosses). Looking at how far XHTML 2.0 went, I'm glad we
>> didn't. If <annotation> (or something similar) would already exist, maybe
>> we'd never had any need to define <ruby> in the first place. But currently,
>> <annotation> doesn't exist.
> 
> So I am arguing that the scope of HTML ruby be limited
> to single-sided ruby and we should address all markup and
> layout issues around it.  Examples of double-sided ruby are
> rare.  Some of them are simply not doable by automatic layout.
> Others can be better addressed by supporting kanbun
> kuten.  Yet others cause the overlapping ruby-base
> or concurrent structure problem.

As I think you will admit from seeing what I wrote above, I tend to 
agree that we should focus primarily on single ruby. But is there not a 
big risk that even if we only permit and support nested ruby, some 
authors will nevertheless create double ruby — either via images or 
tables or — like today — via display:inline-table etc? For that reason, 
I think we should support double ruby as well - in the form of nested 
ruby. Or - if something else than nesting would be prerrable: The 
second ruby text should have a strong stylistic relationship to the 
ruby base (developed and supported by CSS Ruby) but an, if necessary, 
loose semantic relationship to the ruby base.

>> What is there in terms of markup (not layout!) that the ruby proposals
>> currently floating around wouldn't cover?
> 
> Ruby for ruby is certainly not covered.  Is overlapping ruby base covered?

I'll note that nested ruby could allow many intracate levels ...
-- 
Leif Halvard Silli

Received on Wednesday, 29 February 2012 16:03:09 UTC