- From: John Daggett <jdaggett@mozilla.com>
- Date: Sun, 29 May 2011 08:47:34 -0700 (PDT)
- To: W3C style mailing list <www-style@w3.org>
Some comments on the CSS3 Writing Modes spec, based on the 25 May 2011 Editor's Draft. 1. Introduction > CSS3 Writing Modes defines CSS features to support for various... CSS3 Writing Modes defines CSS support for various... "inline base direction" Why "base"? > To avoid confusion, the CSS specifications... Delete "the" > Latin-based "systems" The use of "system" is awkward here. I think you really mean "script" here. Rather than "Arabic-based systems are typically written using a" use something more natural like "Text written in the Arabic script uses a". > See Unicode Technical #22 Referring to this tech note is *highly* problematic in my opinion, since it contains background information on writing systems in addition to what is basically a rough draft of this spec. I think it would be better to refer to *only* the introduction or specific sections. I've said this before, CSS specs should try to be self-contained and not defer essential contents to other documents. > Sections 1.1, 1.2, 1.3 The ordering *after* the intro is odd. Some of the text here seems unnecessary, like the wording in 1.3 saying that this spec builds on CSS 2.1. 3. Introduction to Vertical Text I still think this should be merged with the introduction. And it also probably needs to be labeled as informative. 3.1 Block Flow Direction Doesn't writing-mode affect inline direction? If so, calling this the "block flow direction" property is misleading and inaccurate. The description of this property is a bit jumbled, I think the paragraph starting with "The 'writing-mode' property determines the direction of block flow." should really follow directly after the list of property values. The discussion of SVG 1.1 values really isn't central to the definition of this property and covering those first doesn't answer the basic question "what is this property?". > The content of replaced elements do not rotate due to the writing > mode: images, for example, remain upright. However replaced content > involving text (such as MathML content or form elements) should match > the replaced element's writing mode and line orientation if the UA > supports such a vertical writing mode for the replaced content. As I've said before, I think the spec needs to say more about the handling of form elements, since CSS properties obviously affect the text settings of form elements. In particular, I think we need to provide clear directions as to what happens, either form elements are not shown vertically or they are. Leaving this ambiguous will lead to big interoperability problems, since a form element shown horizontally affects layout very differently from one shown vertically. 4. Inline-level alignment I'm puzzled by this section, it's seems like the focus of this section should be how to deal with the issue of the dominant baseline being different for horizontal vs. vertical text. Specifically, what do the property values for vertical-align mean for vertical writing modes, this isn't addressed. Does 'vertical-align: baseline' imply the center baseline for vertical writing modes? There's also an obvious interaction with text-orientation and text-combine that are completely unaddressed. This needs to be marked as an issue in the draft. While the OpenType baseline tables are referred to, I'd think I'd prefer it if there were less details about this here. I think one of the goals of the line layout spec will be to assure proper baseline table handling and so it would be better to avoid too much detail here that we might need to override later if there's a problem with the wording. 4.2.1 Baselines in TrueType/OpenType fonts > For the ascender and descender metrics, it is recommended to use the > sTypoAscender and sTypoDescender metrics from the font's OS/2 table. > These should match the idtp and ideo baselines (respectively), which, > if present, may be used instead. In the absence of these metrics, the > Ascent and Descent metrics from the HHEA/VHEA table should be used. > The Win metrics can be used as a fallback; however these are intended > as clipping bounds and are not always appropriate for use as em box > measurements. This isn't how work browsers work currently, browsers on Windows use metrics typically supplied by the OS and this has historically been the Win metrics *not* the sTypoAscender and sTypoDescender metrics. This is a somewhat sucky situation, it leads to incompatibilities across OS versions so I think it might be better to resolve that in the line layout spec, especially given that this text has been labeled "non-normative". Although this will probably be obvious to implementors, I think we need to have wording that explicitly *requires* the use of vertical metrics for vertical text layout when the font contains these. I think you can just describe these as "vertical metrics" without getting into OpenType table nitty-gritty details. 5. Introduction to Intrinsic Text Layout Seems like "Introduction to Vertical Text Layout" is a more accurate description of this section. The term "Intrinsic Text Layout" seems a bit baffling. > Each writing system has one or more native orientations. Modern > scripts can therefore be classified into three orientational > categories: > > horizontal-only > Scripts that have horizontal, but not vertical, native > orientation. Includes: Latin, Arabic, Hebrew, Devanagari > vertical-only > Scripts that have vertical, but not horizontal, native > orientation. Includes: Mongolian, Phags Pa > bi-orientational > Scripts that have both vertical and horizontal native orientation. > Includes: Han, Hangul, Japanese Kana This doesn't seem like a very useful classification scheme. For example 'Latin' is listed under "horizontal-only" with Arabic, yet Latin text can be written vertically (e.g. book spines, table headings) but I don't think the same is true for Arabic or Devanagari. I think the point that's being made here is that in general many scripts have a natural orientation, either horizontal or vertical, and some are commonly laid out in both orientations. This means that when laying out various scripts vertically, horizontal scripts are generally laid out in the inline direction. Somehow "bi-orientational" makes me think we're discussing cross-dressing baselines or something. But maybe that's just me. ;) > In modern typographic systems, all glyphs are assigned a horizontal > orientation, which is used when laying out text horizontally. To lay > out vertical text, the UA needs to transform the text from its > horizontal orientation. This transformation is the bi-orientational > transform, and there are two types: > > rotate > Rotate the glyph from horizontal to vertical > translate > Translate the glyph from horizontal to vertical > > Scripts with a native vertical orientation have an intrinsic > bi-orientational transform, which orients them correctly in vertical > text: CJK (Chinese/Japanese/Korean) characters translate, that is, > they are always upright. Other scripts, such as Mongolian, rotate. > (See Appendix B for a list of intrinsic bi-orientational transforms.) While one *can* think of vertical layout in these terms, I don't think it's a particularly insightful way of describing vertical layout. Horizontal scripts are generally laid out horizontally by placing glyphs in sequential locations along the inline axis, which in the vertical text case runs top to bottom. So lines of Latin appear rotated 90 degrees when displayed within Japanese vertical text. Scripts that include characters with a natural vertical orientation such as Han characters and Japanese kana are laid out by stacking glyphs along the inline axis. I don't see the need to talk about "bi-orientational transforms". The last couple paragraphs in this section are comments about the values of the text-orientation property and probably should follow the next section rather than precede it. 5.1 text-orientation I have a lot of qualms about the structure of this property. It doesn't feel like we're giving authors of vertical text documents the right handles here. It's specified at the character level when I think we should be thinking about text spans rather than characters. Why does 'auto' need to be used for backwards compatibility with SVG's glyph orientation properties? It seems to me you could just say that the SVG glyph orientation overrides the value of this property when set to a non-initial value. It feels very weird to be adding property values to support deprecated properties in SVG. I think 'auto' should be the default and be defined to be something along the lines of 'vertical-right'. That's more in the spirit of what 'auto' values are generally used for in CSS. I also don't quite follow the need for three rotate properties, 'rotate-left', 'rotate-right', and the mysteriously named 'rotate-normal'. Is there a use case for either of the combinations below? .oddstyle1 { writing-mode: vertical-rl; text-orientation: rotate-left; } .oddstyle2 { writing-mode: vertical-lr; text-orientation: rotate-right; } Wouldn't it suffice to define this as: text-orientation: auto | stacked | inline where auto uses the script's natural orientation to determine vertical layout, grouping common and inherited spans with orientation of previous script (insert special rule for handling matching punctuation here). stacked (== upright) for scripts that permit stacking, place upright along the inline axis (i.e. Latin letters would stack, scripts with complex joining behavior only if non-joiners are present). inline (== rotate-normal) glyphs are placed side-by-side along the inline direction (or reverse inline in the case of vertical-lr) Another way to formulate this might be to define natural orientation at the script level (with specific rules for handling common/inherited characters) as in the 'auto' case above, and then only use the text-orientation property as a way to specify the override cases: text-orientation: normal | [ stacked( <code-sequence> [,<code-sequence>]* ) || inline( <code-sequence> [,<code-sequence>]* ) ] where: <code-sequence> == [ <script code> | <unicode-range> ]+ Also, why does text-orientation not apply to table rows? That doesn't quite make sense to me. Minor overall comment There are way too many "notes" and some seem like they should be normative, not informative. I would suggest just incorporating many of these into the text unless there's a specific need for green text. ;) It's late here in Tokyo and I'm starting to fade, so I'm going to stop here. I'll try and post more comments on the remaining sections on Tuesday. Regards, John Daggett
Received on Sunday, 29 May 2011 15:48:03 UTC