- From: fantasai <fantasai@escape.com>
- Date: Sun, 02 Mar 2003 13:22:10 -0500
- 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 UTC