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

On 05/29/2011 08:47 AM, John Daggett wrote:
>
> 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"?

Because the actual ordering direction can vary depending on the intrinsic
directionality of the characters in the text content. E.g. Arabic text is
ordered right-to-left even when the inline (base) direction is left-to-right.

>> To avoid confusion, the CSS specifications...
>
> Delete "the"

Okay.

>> 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".

The correct technical term here is actually "writing system", and
not "script". (Japanese, for example, uses a writing system consisting
of four scripts: Han, Hiragana, Katakan, and Latin.)

I can expand it out to "Latin-based writing systems are written..."
if you prefer?

>> 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.

How about you suggest some wording, as I'm not sure what you want here.

>> 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.

Books typically put the "formatting conventions" section after the intro,
because otherwise there's nothing interesting at the beginning. I think
it's fine to leave this here.

> 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.

It doesn't relate to anyone only looking for bidi controls, so I'd rather
leave it here, where it's close to the normative sections it's related to.
Will mark it non-normative, though.

> 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.

Only in the sense that it rotates the line, but it doesn't affect
the ordering of contents within the line. The primary effect is to
change the block flow direction, so I think that's an appropriate
title. If we tried to list every layout side-effect in the title
of every property, the titles would be much more awkward than useful.

> 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?".

Ok, I've shifted the SVG bit into its own subsection at the end of the
section.

>> 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.

As I said before, while I'm happy to add examples of rotated form
elements, I'm drawing the line on any normative prose since the
rendering of form elements is thus far out-of-scope for CSS, and
I'm not willing to bring them in-scope by defining their rendering
in this particular module.

> 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.

The section is organized as follows:

   Introduction to Baselines - this section gives some background information
     on what baselines are, so that the next few sections are understandable.

   Text Baselines - this section defines the 'alphabetic' and 'central'
     baselines. It also defines that the 'alphabetic' baseline is dominant
     in horizontal writing modes, and the 'central' baseline is dominant
     in vertical writing modes.

   Atomic Inline Baselines - this section defines the 'alphabetic' and
    'central' baselines for elements that need them but don't have them,
     e.g. images

   Baseline Alignment - defines how the dominant baseline is used, together
    with 'vertical-align', to control alignment in the transverse dimension
    of the line box.

The definitions from 'Text Baselines' and 'Atomic Inline Baselines' combine
with the rules in 'Baseline Alignment' to define the meaning of the various
'vertical-align' values in vertical writing modes, and the remaining values
(top/bottom/etc) are covered in
   http://www.w3.org/TR/css3-writing-modes/#line-mappings

What case, exactly, did you have in mind that isn't addressed?

> Does 'vertical-align: baseline' imply the center baseline for vertical
> writing modes?

Yes.

> 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.

This is covered by the Line-Relative Mappings section and the definitions
of 'over' and 'under' therein. (Notice how these terms are used in the
baseline alignment sections.)

> 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".

This section was drawn up based on advice from Steve Zilles and
Ken Lunde, so how about you and Steve Zilles figure out what should
be done about it, and I'll edit accordingly. :)

> 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.

Ok, I'll mention that in the intro paragraph that talks about different
tables for horizontal and vertical text.

> 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.

Ok.

>> 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.

Actually, it is true for Arabic or Devanagari. (Less so for Arabic,
but IIRC you see it in crossword puzzles.) The Indic group provided
some Devanagari examples, although they have ignored any requests
for further detail.

> 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.

No, that's not true, either. Arabic is commonly laid out in the anti-inline
direction, although it is sometimes 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. ;)

Lol. Maybe. :) It never occurred that way to me, but maybe others
had the same thought. :)

>> 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".

So, there is a difference between the "stacking" behavior of CJK and
the sideways behavior of Latin. I think it's useful to distinguish
these, and to explain the differences. In particular, we need to note
that some scripts have an intrinsic transform, where it's wrong to do
it the other way (CJK, Mongolian), and for others it's a stylistic
preference (horizontal-only scripts). This is the framework I've come
up with to explain all that.

If you've got a different framework, I can consider rewriting this
chapter using your mental framework, but since I don't have your
mental framework, I don't really know how to do that yet.

> 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.

They're included in the intro by way of connecting the information in
the intro to the 'text-orientation' property in the next section. I
suppose I could shift the transition under the next heading, but I
doubt that'd change much...

> 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.

It's specified down to the character level because it affects different
characters differently. It's designed to be used in spans, though.

> 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.

The non-initial values in SVG have their own particular behaviors.
If we can do that, great. But I'm not sure we can do that, we'd have to
check whether we can change the default behavior for SVG.

I also have a slight preference for having 'text-orientation' override
'glyph-orientation' rather than the other way around, given we're
deprecating the latter. But that's not a strong preference.

> 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.

So, the reason we picked 'vertical-right' was because there is theoretically
a 'vertical-left' value which we didn't want to tackle right now, because
it has some very ... interesting bidi implications. It would be similarly
defined, except horizontal scripts would be rotated 90deg counter-clockwise
instead of 90deg clockwise. (This would have Arabic go top-to-bottom, the
same direction as CJK text, avoiding bidirectional layout in such mixes.
But it involves overriding the Unicode Bidi Algorithm in some tricky ways.)

> 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;
>    }

This one is a workaround for the lack of 'vertical-left' in the spec.
If you want to place Arabic in the same inline flow as the CJK, then
you need to do this.

>    .oddstyle2 {
>      writing-mode: vertical-lr;
>      text-orientation: rotate-right;
>    }

The second one has the use case of Latin or Cyrillic in Mongolian
text. If you're doing anything other than a simple run, you might
want to switch into rotate-right, which does a better job of
typesetting horizontal scripts. This is not as strong of a use
case, however.

> 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).

Interesting. You want Unicode-bidi-style neutral-resolution for character
orientation? That could be nifty for some of these really hard-to-categorize
cases. Let's talk about that at the F2F.

> 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).

All scripts would stack one way or another, but yes.

> inline (== rotate-normal)
>    glyphs are placed side-by-side along the inline direction (or reverse inline in the case
>    of vertical-lr)

Another thing to consider about the rotate-* values is that they trigger
a horizontal typesetting mode. So it really is about rotation, and not
about vertical text. The alphabetic baseline table is used, ruby and
text decoration are placed as for horizonal writing modes, etc. It's
useful for setting vertical text in horizontal-only documents, e.g. for
table headers or figure captions in an English document, where you don't
want vertical-text typesetting.

> 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>  ]+

Uhhh, I'd like to avoid this for right now... Sticking overrides into
a property definition like this seems like a bad idea. Let's consider
an @rule if needed sometime in the future, ok?

> Also, why does text-orientation not apply to table rows?  That doesn't
> quite make sense to me.

What would it do for table rows?

> 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. ;)

Ok, I'll do an audit and we'll see where we are tomorrow. :)

> 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.

Ok.

~fantasai

Received on Wednesday, 1 June 2011 11:46:59 UTC