W3C home > Mailing lists > Public > www-style@w3.org > November 2002

CSS3 Text: Multidirectional Text

From: fantasai <fantasai@escape.com>
Date: Thu, 28 Nov 2002 02:25:19 -0500
Message-ID: <3DE5C4DF.4090402@escape.com>
To: www-style@w3.org

Section 3.1 Text layout introduction

     You might consider formatting part of the third paragraph as
     a list. If not, add a comma after 'font'.

     The fourth and fifth paragraphs could be written more clearly,
     and should be combined.

     > CSS2 specified the 'direction' property which is a subset of
     > the 'writing-mode' property as it only determines an inline
     > progression.

     rewrite as

     "CSS2 defined the 'direction' property, which is a subset of
      the CSS3 'writing-mode' property, to specify the inline
      progression."

Section 3.2: 'writing-mode' and 'direction'

     | bt-lr
     |    Sets the inline progression to bottom-to-top, and
     | the block progression to left-to-right. This value only
     | exists to cover the case of the direction property value
     | 'rtl' applied to an element where the current writing-
     | mode property value is 'tb-lr'. The direction property
     | is set to 'rtl'.

     It seems this should exist to cover the case where direction
     is 'ltr', not 'rtl'. If the block progression is left to right,
     then any horizonal script going down will be going right to
     left on its side. The reverse would be left to right.

     } - Arabic   [ - English

     v v
     } }
     } }   <- Arabic text is going tb-lr
     } }
     } v
     }
     v ^
       [
     v [   <- English text is going bt-lr
     } [
     } ^
     }
     v v
       }
       v

     | An inline-level element that has a different writing-mode
     | value than its parent becomes an inline-block element.

     If I have

     <para>Arabic paragraph with rl writing mode <code>stuff</code>
     </para>

     code {writing-mode: lr}

     why does <code> need to become an inline-block? Shouldn't
     this only take effect if the block progression changes?

     | Here is a diagram of a horizontal flow...

     What are 1, 2, & 3 labeling?

     Is 2 an image or other replaced element? If so, why does it turn?

     | This effect is known as "Tate chu yoko".

     You might want to add "In Japanese, this effect...".

     | .hinv {writing-mode: lr-tb; display: inline-block;}

     Is this necessary? A few lines above this it's said that
     changing the writing mode would automatically create an
     inline block.

     | This is an application of changing the flow of an
     | inline element as described earlier. Line breaking
     | is normally disabled for such runs of text. This
     | can be accomplished using the CSS 'white-space:
     | nowrap' property setting.

     Why would this be necessary? Are inline-blocks constrained
     by the line-height?

     | For the 'direction' property to have any effect on inline-
     |level elements, the 'unicode-bidi' property's value must be
     | 'embed' or 'bidi-override' and the glyph orientation of the
     | characters within the element must be 'auto' or 90/-90'
     | degree in vertical layout or 0/180 degree in horizontal
     | layout.

     What does glyph orientation have to do with the direction of
     character flow?

     | Similarly, modifying 'direction' after 'writing-mode'
     | changes effectively the 'writing-mode' value to the
     | opposite inline progression.

     So,
     p {
       writing-mode: lr-tb;
       direction: ltr;
     }

     results in a right-to-left inline progression?

   glyph-orientation-vertical -

     | Conforming user agents may only support the following
     | values: 0deg, 90deg, 180deg and 270deg, other values
     | can also be supported.

     This sentence is self-contradictory. It should be written as
     "Conforming user agents must support the following values:
      0deg, 90deg, 180deg, 270deg; other values may also be
      supported."

     | Conforming user agents may do the following in
     | increasing levels of supports:
     |
     |   1. support only the 90deg value,
     |   2. support the 0deg, 90deg, 180deg and 270deg values,
     |   3. support all values above and any number of additional values.

     This section should be taken out, as it's already explained
     above. Support of only the 90deg value should not be
     sufficient for conformance because vertical CJK text looks
     ridiculous if the glyphs are turned on their sides. The
     traditional format for these languages *is* vertical, and
     the glyphs are always written upright. Unlike horizontal
     scripts such as Latin and Arabic, which vertically orient
     short runs of text for layout purposes, their main text
     is often written with top-to-bottom inline progression. It
     will probably become a very common situation for a
     Taiwanese web page to specify "writing-mode: tb-rl" on the
     root element. However, if a browser supporting only 90deg
     and not 0deg became significant, it would be necessary to
     avoid displaying text with vertical inline progression in
     this browser. The two options are either a) reverting to
     lr-tb or b) browser-sniffing, neither of which is an
     attractive solution for the web.

     | A value of "0deg" indicates that all glyphs are
     | oriented with the bottom of the glyphs toward the
     | inline progression, resulting in glyphs which are
     | stacked vertically on top of each other. A value
     | of "90deg" indicates a rotation of 90 degrees
     | clockwise from the "0deg" orientation. For
     | characters which have this property set to 90 or
     | 270 degree, reordering is first applied according
     | to the Unicode Bidi algorithm and then the resulting
     | glyphs are rotated according to the <angle> value.
     | The rotation specified by this value is applied to
     | the glyph representations of all assigned Unicode
     | character codes.

     The system would be less error-prone if 0deg were
     defined to have all glyphs oriented with the bottom
     towards the bottom of the block and 90deg to have the
     bottom of all glylphs in the direction of the block
     progression.

     This way, I can specify "vertical-orientation-vertical:
     0deg" for something and it will come out "upright"
     whether writing mode is 'tb-lr', 'tb-rl', 'bt-lr', or
     'bt-rl'. I can also specify "vertical-orientation-
     vertical: 90deg" for a run of horizontal script and/or
     punctuation (e.g. for <code>) and it will display in
     the correct direction in all four vertical writing
     modes.

     | Hebrew and Arabic text are also rotated 90 degree
     | clockwise.

     Rotated 90 degrees clockwise would be inappropriate
     for tb-lr text.

     I'm not familiar with the differences between full-
     width and half-width Roman text, so I can't comment
     on that part.

     | The diagrams below illustrate different uses of
     | 'glyph-orientation-vertical'.

     You need to make it clear that the Roman text is
     encased in an element.

   glyph-orientation-horizontal -

     | A value of "0deg" indicates that all glyphs are
     | oriented with the right edge of the glyphs toward
     | the inline progression

     Wouldn't this result in upside-down Arabic text?
     The right edge of this character:    .
                                          >
     is at the vertex. To orient the right edge toward
     the inline progression (rtl), one would have to
     rotate it 180 degrees.
         <
         '

     | The value of this property affects both the
     | alignment and width of the glyph area generated
     | for the affected glyphs. If a glyph is oriented
     | so that the normal orientation of the glyph is
     | parallel to the dominant-baseline, then the
     | vertical alignment-point of the rotated glyph
     | is aligned with the alignment-baseline
     | appropriate to that glyph. The baseline to which
     | the rotated glyph is aligned is the horizontal
     | baseline identified by the "alignment-baseline"
     | for the script to which the glyph belongs. The
     | width of the glyph area is determined from the
     | vertical width font characteristic for the glyph.

     This whole paragraph is very confusing. It uses
     terms that haven't been defined and doesn't
     refer to their definitions. Also, what does
     orienting a glyph "so that the normal orientation
     of the glyph is parallel to the dominant baseline"
     mean?

     I also don't see anything comparable in the vertical
     glyph orientation text. Is it missing from there
     or superfluous here?

     | Please note that hebrew and english are chosen as
     | element names for explicitness only; in general,
     | element names should convey structure without
     | reference to language.

     Why don't you just use the lang attribute, then?


That's all for now.

~fantasai
Received on Thursday, 28 November 2002 02:24:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:17 GMT