Re: agenda+ css-writing-modes-3 review

Hello all,

As I mentioned previously, I think that because the SVG 1.1 vertical
writing spec was vaguely written and inconsistently implemented, clarity
and simplicity in the new spec should trump a diligent effort to capture
all the quirks of the old.  That said…

*Regarding `writing-mode`:*

My only recommendation would be to add a note suggesting that authors (and
authoring agents) who choose to use the SVG 1.1 values for compatibility
with old user agents, use the "lr" values when direction is ltr and the
"rl" values when direction is rtl.  That should handle the behavior in
Presto and possibly other rendering tools.

I would not, however, recommend that modern user agents treat the old
values differently when displaying content.  The
"inline-progression-direction" in the SVG layout instructions incorporates
both the "block flow direction" and the "inline base direction" using the
CSS spec terminology.  Although the SVG 1.1 description of `writing-mode`
says that it sets the inline-progression-direction, the text also very
clearly states that the direction can be modified by both the `direction`
property and by Unicode bi-directionality.  In other words, it effectively
only sets the block flow aspect of the inline-progression-direction.
Importantly, the SVG 1.1 specs clearly state that `direction` takes
precedence over `writing-mode` when it comes to the text-anchor aspect of
SVG layout.

*Regarding `text-orientation` and `glyph-orientation-vertical`:*

1) The SVG 1.1 glyph orientation values may be specified as 0 or 90,
without units, instead of 0deg or 90deg, as well as the equivalent in rad
or grad.  I don't think the way it is currently written incorporates that;
it seems to be treating them as fixed string values.

2) I am not clear whether or not you are recommending that user agents
*ignore* other values of glyph-orientation-vertical and all values of
glyph-orientation-horizontal, or are just leaving them undefined/optional.

3) There is some inconsistency with SVG 1.1 re the interaction between
`upright` orientation and `rtl` direction.  I think the net effect is the
same for any real-world use case, but I wanted to highlight it here so
others could take a look (if you haven't already carefully analyzed the
issue.)

In the CSS spec, it is stated as part of `text-orientation` that an
`upright` value overrides `direction`: "This value causes the used value of
direction to be ltr, and for the purposes of bidi reordering, causes all
characters to be treated as strong LTR."

In SVG 1.1, the restriction is stated as part of the `direction` property:
 "The ‘direction’ property applies only to glyphs oriented perpendicular to
the inline-progression-direction, which includes the usual case of
horizontally-oriented Latin or Arabic text and the case of narrow-cell
Latin or Arabic characters rotated 90 degrees clockwise relative to a
top-to-bottom inline-progression-direction."

The SVG 1.1 text is problematic when it comes to mixed-orientation glyphs
in vertical text (how do you handle bidi re-ordering if direction does not
apply to the vertical glyphs?).  It is also not clear how this interacts
with the SVG `text-anchor` start/end values.  So I would stick with the new
text unless someone else sees a problem.

*Some other comments for Fantasai et al:*

Would it be appropriate to add text that specifically states that the HTML
dir attribute and <bdo> element should be implemented in a way that sets
the corresponding CSS properties?  E.g., through !important rules on a user
agent style sheet?  This affects property inheritance in inline SVG in HTML
documents: currently most browsers implement it so that the SVG content
inherits the directionality set using the HTML attributes, but not all
(specifically, not in Internet Explorer; haven't tested in Edge).

I notice that the sideways-right and sideways-left options have been
dropped.  There's some related cleanup still required (the no longer
included values are mentioned elsewhere in the text), but my main question
is will the remaining `sideways` value be influenced by the writing-mode
(vertical-rl versus vertical-lr)?  I was really looking forward to having
easy vertical text in chart axis labels with left-to-right block
progression direction where the top and bottom of each line of text still
nicely matched up with the top and bottom of the block.