W3C home > Mailing lists > Public > www-style@w3.org > March 2003

CSS3 Text: writing-mode & direction

From: fantasai <fantasai@escape.com>
Date: Sun, 02 Mar 2003 13:22:10 -0500
Message-ID: <3E624BD2.3020007@escape.com>
To: www-style@w3.org

CSS3 Text, Section 3.2
http://www.w3.org/TR/2003/WD-css3-text-20030226/#Progression

Left-to-Right Block Progression
-------------------------------

   This I find very amusing:
     http://www.w3.org/Style/2003/css3-text-last-call#answer121

   Etan and I both made the same comment about 'direction'
   values being switched for "writing-mode: bt-lr". The reply
   to my comment (#121) tries to explain that the text is correct
   as it stands--that sideways English in a left-to-right block
   progression goes from top to bottom, then left to right.
   Meanwhile, the reply to Etan's comment (#177) acknowledges the
   error and updates the document.

   The best part is that, consistent with the inconsistency, only
   part of the error is fixed, leaving

     # bt-lr
     #     Sets the inline-progression to bottom-to-top,
     #     and the block-progression to left-to-right.
     #     This value exists only 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 'ltr.

   So, when 'writing-mode' is set to 'tb-lr' and "direction: rtl"
   is applied, the writing mode becomes 'bt-lr' and the 'direction'
   becomes 'ltr'!

   Anyway, Ian said I should keep my posts trim, so I'll stick to
   the point now. :) We'll come back to that answer121 later,
   though, because it's important.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Affect of Glyph Orientation on Character Ordering
-------------------------------------------------

      # For the 'writing-mode' property to have any effect on
      # inline-level elements, one or both of the following
      # conditions must be met:
      #
      #  * the new inline-progression is perpendicular to the
      #    parent's inline-progression or
      #  * the 'unicode-bidi' property's value is 'embed' or
      #    'bidi-override' and one of the following conditions
      #    is met:
      #       o the flow is vertical and the 'glyph orientation'
      #         is 'auto', '90deg (or equivalent), or -90eg (or
      #         equivalent)
      #       o the flow is horizontal and the 'glyph orientation'
      #         is '0deg (or equivalent), or 180deg (or equivalent).

   In comment 127, I wrote:
      > What does glyph orientation have to do with the direction of
      > character flow?

   The reply was:
      | It just means that you only apply any sort of embedding
      | and direction override to characters that are laid out
      | 'upright' in horizontal flow or 'on the side' in vertical
      | flows.

   I re-iterate my question: Shouldn't the letters be laid out in
   the same order no matter how I rotate the individual glyphs?

   If you're trying to protect against having characters with their
   tops turned toward the inline-progression, this is not a very
   effective way to do it. Suppose I specify

    p { writing-mode: tb; glyph-orientation-vertical: 0deg; }

    <p>Chinese text <span>HEBREW</span> more Chinese...</p>

    Unless I can apply some kind of override to the <span>, I'll get

                    C  W  C
                    h  E  h
                    i  R  i
                    n  B  n
                    e  E  e
                    s  H  s
                    e     e
                    .  m
                    .  o  t
                    .  r  e
                       e  x
                          t

   Assuming the Hebrew characters are upright as specified by
   glyph-orientation-vertical, they should go from top to bottom.
   (If they were sideways, they should go from bottom to top.)


   And then, what happens when the glyph-orientation is 45deg?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Rotating Image Example
----------------------

   In comment 123, I wrote:
      > Is 2 an image or other replaced element? If so, why does
      > it turn?

   The reply was:
      | Document updated, 2 is not turned, but shows a different
      | image in the vertical flows, could be better, but I don't
      | have access to the original pictures.

   The draft was updated:
      # The image shown in the vertical flows is not turned, but
      # instead illustrates what would be the desired geometry of
      # the image in such flows.

   This is unnecessarily confusing. Fix the images so they all
   face the same way. A photograph would not be turned on its
   side; neither would an electric field diagram. If you can't
   fix the pictures, let me know and I'll fix them for you.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Line-breaking in Perpendicular Inline Blocks
--------------------------------------------

   I wrote:
      > | 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?

   Comment 126 answered the second question:
      | Not for some line-stacking strategy (see CSS3 line module)

   but not the first.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Direction: Interpretation of 'ltr' and 'rtl'
--------------------------------------------

    # The values 'ltr' and 'rtl' have to be interpreted relative
    # to the line direction.

"line direction" isn't defined, afaict. It should be "relative
to the block progression".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Interaction of Writing-Mode and Direction
-----------------------------------------

    # Note: The 'writing-mode' and 'direction' properties
    # interact with each other. As such, 'writing-mode'
    # resets the 'direction' value. Similarly, if modifying
    # 'direction' after 'writing-mode' introduces a change
    # of inline-progression, the 'writing-mode' value will
    # be updated to reflect the new inline-progression.

How does this work in the context of the cascade?
'writing-mode' can easily reset 'direction', but 'direction'
cannot reset 'writing-mode' without knowing the value of
'writing-mode'.

Take, for example, this:

    .class { direction: rtl; }

    element { writing-mode: lr; }

    <element class="class">

What is the final writing-mode and direction? How did you
know?

~fantasai
Received on Sunday, 2 March 2003 13:21:30 GMT

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