Re: [css3-text] Before It Becomes a PR

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