[css3-writing-modes] comments on the spec, part 1

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