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

Re: CSS3 Text: Multi-Directional Scripts in Vertical Inline Progression

From: fantasai <fantasai@escape.com>
Date: Tue, 15 Apr 2003 17:44:04 -0400
Message-ID: <3E9C7D24.4010309@escape.com>
To: www-style@w3.org

Michel Suignard wrote:
> See my answers online.
(inline)
> | From: fantasai [mailto:fantasai@escape.com] 
> | 
> | The reason why you should /not/ use 'direction: rtl' on a 
> | Chinese or English text:
> | 
> | author.css
> |    element { writing-mode: tb-lr }
> | 
> | user.css
> |    * { block-progression: tb !important }
> 
> I don't see this as a realistic scenario.

Then consider the following, which would have the same effect:
   - block-progression: lr; direction: rtl; in a browser with no vertical
     text support
   - element { writing-mode: tb-lr }  .class { block-progression: tb }

> Furthermore, the normal usage of a 'block-progression:lr' is to have
> 'direction:rtl' as it will do the right thing for Mongolian which is the
> typical usage for that combination, and the upright characters will flow
> top to bottom which is again expected. 

The point is not whether block-progression: lr and direction: rtl
are a sensible combination. The point is that if one gets overridden,
for whatever reason, be it user stylesheet or lack of browser support,
the layout breaks. This is a direct result of the way properties are
currently defined in the CSS3 Text working draft and not an unavoidable
problem in the language. I think that since we have the chance to
avoid the problem, we ought to do so.

> | The net result is "writing-mode: rl", which is 
> | *inappropriate* for horizontal left-to-right scripts.
> | 
> | 'direction' controls the directionality of the element's 
> | text. This is different from the stylistic inline 
> | progression, and you get problems if you conflate the two.
> 
> I don't agree with this. 'direction' controls the inline-progression for
> block element, it doesn't change the inherent character directionality
> unless 'unicode-bidi:bidi-override' is also used. In that aspect,
> 'direction' is a bit overloaded, but imo we don't need another
> property/concept to control inline-progression.

No, we don't need another property to control inline-progression,
but the two concepts /are/ distinct. Chinese that just happens to
be in an lr block progression does not acquire right to left
directionality, even though has a "right-to-left" (top-to-bottom)
inline progression.

There's a longer explanation of this in my other post. (If I'm not
making sense, let me know. It's a bit confusing, and I'm not sure
that my writing is as lucid as it should be.)

> Inline
> ------ 
> All glyphs are laid out top to bottom regardless of inherent direction.
> The embedding levels, as determined by the bidirectional algorithm
> [UAX9], are used to set the orientation of some glyphs (see following
> prose). 
...
> For this value of 'glyph-orientation-vertical', the directionality of
> characters cannot be changed by the 'direction' property.

If I have an override, is it not equally valid when I choose
"glyph-orientation: inline"? The 'direction' property should apply
*before* rotation. It needs to factor into the calculation of
embedding levels.

> ...
> | If the inline progression is right-to-left, it would make 
> | sense for Mongolian to also go from right to left. This kind 
> | of contextual progression is what the "inline" (context) 
> | value should do: if the block's inline progression is 
> | right-to-left, it should go from right to left as well, not 
> | left to right. Right now it seems they're using overrides for 
> | this [1], which IMO should be avoided. (It doesn't handle 
> | mixed scripts very well.)
> 
> This is a case I had not thought of, but it could be added as a
> modification of the 'glyph-orientation-horizontal: auto' now reads like
> this:
> <<
> auto 
> ----
> The glyph orientation relative to the inline-progression is determined
> automatically based on the Unicode character code of the rendered
> character.
> - Full-width ideographic and full-width Latin glyphs (excluding some
> ideographic punctuation and bracket symbol) are oriented as if an
> <angle> of "0deg" had been specified. 
> - Ideographic punctuation and other ideographic characters having
> alternate horizontal and vertical glyphs MUST use the horizontal glyph. 
> - Glyphs from the Mongolian script are also oriented as if an <angle> of
> "0deg" had been specified, however they are stacked vertically word by
> word. 
> - Other glyphs, including Hebrew and Arabic are set as if an <angle> of
> "0deg" had been specified.
> 
> We could change the the definition for Mongolian script in the case of
> 'auto' to read as follows:
> 
> - When the 'direction' value is 'ltr', glyphs from the Mongolian script
> are also oriented as if an <angle> of "0deg" had been specified, however
> they are stacked vertically word by word.
> - When the 'direction' value is rtl, glyphs form the Mongolian script
> are oriented as if an <angle> of "270deg" had been specified. 

I suspect this would be very complicated to implement, Michel,
as well as being awkward typographically when longer words are
involved. (Judging by the text I have in front of me, a
significant proportion of Mongolian words are 2em long or
longer.)

It is better, IMO, to let the default value honor the Unicode-
assigned directionality always, and to let the "inline" or
"context" value allow the direction change.

Those who want the stacking effect can add extra markup to
create inline blocks. I've only seen this effect for individual
letters (which can be handled by glyph-orientation: 0deg) and
very short words--probably because these fit into the line
without stretching it.

~fantasai
Received on Tuesday, 15 April 2003 17:43:23 GMT

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