- From: fantasai <fantasai@escape.com>
- Date: Thu, 28 Nov 2002 02:25:19 -0500
- 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 UTC