RE: CSS3 Text: writing-mode & direction

Fantasai, see my answers online

Michel

| -----Original Message-----
| From: fantasai [mailto:fantasai@escape.com]
|
| 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.

You are absolutely right. I read your comment first and should have
updated accordingly when I answered  Etan and realized the issue. To be
properly fixed, the quoted text should have 'rtl' replaced by 'ltr'.

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

When we discussed with Bidi expert, it was clear that they NEVER wanted
Hebrew to be rendered as you suggest. So it seems better to say bidi
re-ordering only happen when text is on the 'side' in vertical flow
 (and even then you have to be careful concerning brackets). That
 pathological case shown in your example is disallowed by the spec
 (read description of glyph-orientation-vertical:<angle>)
I however realized when reading it that it might be useful to reinforce
the point that for any other values other than 90 and 270 no
 re-ordering occurs. (and similar point for
 glyph-orientation-horizontal)

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

No re-ordering as per clarification above

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

Will be fixed. I got new images from the original author (Bert Bos)

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

It is not necessary. I think the best solution is to remove the 2 last
sentences. There is nothing magical about this case. I expect the block
width of such an inline-block to be its minimum width. In most cases
 you want the minimum width to be the max width, and for that that you
 need to prevent word wrapping. Maybe a note could still be useful.

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

Yes

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

I guess the only solution is to make 'direction' a constituent property
of writing-mode, and writing-mode would become a short hand for
'direction'. It then becomes part of the larger issue of what means to
'get' a shorthand property. We would also probably need another
 property to set the block progression.
---
Michel

Received on Tuesday, 4 March 2003 10:48:54 UTC