- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 29 Feb 2012 17:02:29 +0100
- To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Cc: "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>, Martin J. Dürst <duerst@it.aoyama.ac.jp>
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