- From: Masayasu Ishikawa <mimasa@w3.org>
- Date: Thu, 28 Nov 2002 01:11:02 +0900 (JST)
- To: www-style@w3.org
- Cc: w3c-html-wg@w3.org
Dear CSS Working Group (and www-style subscribers), The following comments are the Last Call comments from the HTML Working Group on "CSS3 module: Ruby", at: http://www.w3.org/TR/2002/WD-css3-ruby-20021024/ I will send purely editorial comments separately later. ========== 2.2 What is ruby? - After Figure 2.1.2, the spec says as follows: In the first example, a single annotation is used to annotate the base sequence. This simple case is typically referred as a 'group' ruby. The term "group ruby" here looks a bit confusing. The Ruby Annotation spec used to call "complex ruby" as "group ruby", and changed that term according to comments from Japanese typography experts (during Ruby Annotation Last Call). Now the term "group ruby" is used for "simple ruby". Although the Glossary in Ruby Annotation REC includes the term "group ruby", Personally I've never heard that term in Japanese typography - it's sometimes called "taigo ruby" (per-word ruby), though. In fact in the Ruby Annotation spec, the term "group ruby" only appears in the glossary section and nowhere else. Maybe it should have been removed from Ruby Annotation. Anyway, unless it's really necessary, it would be better to avoid the term "group ruby" here. The usage of "group ruby" in fugures 3.2.2 and 3.2.3 looks confusing. - In the following paragraph, the term "mono-ruby" is used without explanation. People familiar with Japanese typography can make sense of it, but it would be helpful to add it to the glossary, like Ruby Annotation REC. 3.1 Ruby specific 'display' property values - In the first paragraph, "HTML markup" should read "XHTML markup" (or "XML markup"). Ruby Annotation REC explicitly removed "HTML markup" for ruby found in earlier drafts. - In the last paragraph, it says: Conforming CSS3 user agents may not implement these ruby-related display' property values if they only support XHTML applications. We wonder if it's appropriate to pre-define CSS conformance for "XHTML applications" like this, without reservation. There may be various kinds of "XHTML applications", and some of them might want to require support for CSS3 Ruby module as part of its conformance (say, XHTML-based simple markup language for typographic data exchange, similar to JIS X 4052). We'd prefer to remove this paragraph. 3.2 Ruby box model - In the paragraph after Figure 3.2.3, it says In the example above, the rtc element preceding the rbc element ... but at least in the case of XHTML ruby markup, the rtc *element* will never precede the rbc element, though, arbitrary XML markup could be defined so that an rtc-equivalent element can precede an rbc-equivalent element. Anyway, to explain ruby box model, it would be clearer to say "ruby text" rather than "the rtc element" and "ruby bases" rather than "the rbc element", or, make sure to explain that the word "preceding" refers to the visual order and not necessarily the logical order of elements. - In the second bullet of the list of exceptions, it says: * the equivalent of the cells: the rb element and the rt text element can only contain inline-level elements. This also means that a ruby element cannot be embedded into another ruby element. We don't quite understand why "[t]his also means". In the first bullet of this list it clearly says that the ruby box is an inline element, so the second sentence is not the corollary of the first sentence. Ruby Annotation explicitly imposed that restriction (i.e. prohibition of nesting of ruby), and if CSS3 Ruby imposes similar restriction, fine, but that should not be just because rb and rt can only contain inline-level elements. - In the last paragraph, it says: Finally, a conforming UA must not display the content of the rp element [RUBY]. The purpose of that element is to allow pre-existing UAs to parenthesize ruby text content. We think this is outside the scope of this specification. This spec doesn't define any specific display value for "rp" (or anything equivalent), and its rendering should be determined according to its display value. An XHTML 1.1 user agent may define something like rp { display: none } in its user agent default style sheet, but this spec would not be an appropriate place to mandate that. Otherwise, what's an "rp" element? Is it any element in any namespace with the local part "rp"? 4.4 Ruby annotation spanning: the 'ruby-span' property - Similar to our previous comments on conformance, we think this spec should not say too much about XHTML applications' behavior. In general, we're not fond of "special-casing" XHTML. - What will happen if the value of attribute 'x' (which is supposed to be a number) is "0"? Although the Ruby Annotation spec doesn't allow the value "0" for the rbspan attribute, this specification per se doesn't seem to prohibit that value for the 'ruby-span' property, and HTML 4 defined a funny behavior for similar attributes, namely rowspan and colspan attributes in table, when the value is "0". It would be better to clarify what is supposed to happen in this spec in that case. cf. http://www.w3.org/TR/html4/struct/tables.html#adef-rowspan - The example in this section is not quite appropriate. It sets the following style rule: myrtc { display: ruby-text-container; } and an XML example uses two "myrtc" elements, yet this example doesn't specify any 'ruby-position' property. Since the initial value for the 'ruby-position' property is "before", it's effectively the same as myrtc { display: ruby-text-container; ruby-position: before; } for those two "myrtc" elements, and in section 4.1 the spec explicitly says as follows: If two rtc elements are set with the same ruby-position value, (for example both 'before'), the relative position of the two elements is undefined. This setting should not be used. So the example should specify appropriate ruby-position for each "myrtc" element. ========== Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium for the HTML Working Group
Received on Wednesday, 27 November 2002 11:11:05 UTC