Re: CSS3 Text: glyph-orientation, writing-mode, & direction

Michel Suignard wrote:
> fantasai wrote:
> |    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
> |          <ASCII rendering>
> | 
> |    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.

As I expected to get or as I said it should be?

> That pathological case shown in your example is disallowed by the spec
> (read description of glyph-orientation-vertical:<angle>)

Yes, you're right. I missed that. What happens, though, when the entire
block is Hebrew? (The situation is analogous to an entire English block
set for left-to-right block progression.) You should specify explicitly
how character ordering is dependent on glyph-orientation--in a separate
sub-section, perhaps, rather than under the <angle> value. 'writing-mode', 
'direction', and 'glyph-orientation' can then all refer to this section.

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

I'm not so sure that's a good idea. A value of 95deg is perfectly
reasonable, and, other than the glyph rotation itself, should be
handled like 90deg. The rules you state here should be for ranges,
I think.

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

I'm not sure what you mean here. If the inline-block's width is
unconstrained--which you say it can be--then it will take up the max
width.

> | Interaction of Writing-Mode and Direction -
> | 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'.
> 
> 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.

I suggest 'block-direction':  block-direction: tb | rl | lr

Syntactically, 'writing-mode' should behave like 'white-space'.
What do you mean by 'get' a shorthand?

Received on Tuesday, 4 March 2003 17:48:05 UTC