- From: fantasai <fantasai@escape.com>
- Date: Mon, 14 Jul 2003 00:03:15 -0400
- To: www-style@w3.org
Ian Hickson wrote: > > The spec is supposed to be frozen while in CR, so that implementors have > the chance of implementing the spec. The spec is also supposed to have gone through sufficient review to ensure that it makes sense to try implementing it. http://www.w3.org/TR/2003/CR-css3-text-20030514/ : # For the 'direction' property to have any effect on inline-level # elements, the following conditions must be met: # * the 'unicode-bidi' property's value MUST be: # o 'embed' or # o 'bidi-override' # and: # o the 'glyph-orientation-vertical' value MUST NOT be # inline for vertical flow orientation, or # o the 'glyph-orientation-horizontal' value MUST NOT be # inline for horizontal flow orientation. The 'inline' value of glyph-orientation-vertical, if you look it up, specifies that # - Glyphs for all characters in even embedding levels are rotated # 90 degrees clockwise from the "0deg" orientation. # - Glyphs for all characters in odd embedding levels are rotated # 90 degrees counter-clockwise from the "0deg" orientation. The Unicode embedding and override settings should take effect for 'inline' as well; correctly orienting the glyphs for 'inline' requires that the embedding levels be correctly resolved, and therefore the exception for 'inline' should not be there. # - If the glyph orientation is 90 degree clockwise, the corresponding # characters are treated as normal (directionality derived from # character property) if the 'block-progression' value is 'rl', but # 'R' (right-to-left) if the 'block-progression' value is 'lr'. # - If the glyph orientation is 270 degree clockwise, the corresponding # characters are treated as 'L' (left-to-right) if the # 'block-progression' value is 'rl', but normal (directionality derived # from character property) if the 'block-progression' value is 'lr'. This makes no sense. Why should a character's directionality be honored in one block progression and not in the other? # Conforming user agents MUST at least support the 'auto' and "90deg" value. There is no need to require the 90deg value. # The user agent MAY round the actual value of the angle to the values of # glyph rotation supported by the user agent. However, this does not # affect the computed value. given # Although any angle value may be used, the behavior related to the value # is determined by rounding it to the nearest multiple of 90 degrees. what does not rounding the value signify? # glyph-orientation-horizontal ... # inline # All glyphs are laid out left to right 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)... # - Glyphs for all characters in even embedding levels are oriented as if # an <angle> of "0deg" had been specified. # - Glyphs for all characters in odd embedding levels are rotated 180 # degrees from the "0deg" orientation. This is pretty much useless. Arabic should not be written upside down just because CSS3 Text decided left-to-right is the definitive horizontal direction. What *would* be useful is having vertical scripts (i.e. Mongolian) assume the direction of the surrounding text. # auto # ... Glyphs from the Mongolian script are oriented as if an <angle> of # "90deg" had been specified. ... # If the glyph orientation is 90 degree, glyphs from the Mongolian script # are treated as 'R' (right to left), other characters are treated as 'L' # (left-to-right). This wasn't in any previous drafts. It is effectively specifying that in horizontal flow, Mongolian should be treated as an rtl script. Traditional Mongolian is a vertical script. In horizontal texts such as those in English and horizontal Chinese, it is written, like the text's dominant script, left to right. The Unicode standard assigns its character code points left-to-right directionality (L). The CSS-specified default behavior *should not override the default Unicode behavior*. *This* is why drafts should go through at least one public review before going CR. This particular problem was pointed out to me when Martin Heijdra asked for an explanation; one of Microsoft's script engine specialists was concerned that CSS3 Text would break all their work on Mongolian support. # If the glyph orientation is 180 degree or 270 degree clockwise, the # corresponding characters are treated as 'L' (left-to-right). Why should BiDi be disabled for upside-down text? On another point, character shaping does not appear to have been considered at all. According to UAX 9*, it takes place after BiDi reordering; thus interpreting literally the spec's directionality overrides would wreak havoc on affected texts in such scripts as Arabic and Mongolian. * http://www.unicode.org/reports/tr9/#Shaping # <script> # ... All characters in the element are reclassified as belonging to # this dominant script. There doesn't seem to be a way of influencing an element's dominant script without reclassifying all characters in the element (which is a bit extreme). And then there are the unreasonable interdependencies between 'direction' and 'block-progression', which I tried to explain in http://lists.w3.org/Archives/Public/www-style/2003Apr/0116.html To insist that CSS3 Text must be kept stable for implementation is to condemn this module to be unfit for it. (Sorry, Ian. I don't mean to direct this at you.) *packs up the soapbox and goes off to do something less insane than challenging the W3C* ~fantasai
Received on Monday, 14 July 2003 00:02:54 UTC