- 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