Re: [css-writing-modes] Computed values of obsolete writing-mode values

On 09/17/2015 01:26 PM, Jonathan Kew wrote:
> On 17/9/15 14:15, Koji Ishii wrote:
>> The spec defines SVG 1.1 values "treat as" CSS values[1].
>>
>> When these values are serialized, are they supposed to keep its original
>> string, or are they supposed to be CSS?
>>
>> For example, what would we expect to see:
>>    <div id=test style="writing-mode: tb-rl"></div>
>> and
>>    console.log(getComputedStyle(test).style.writingMode);
>> ?
>>
>> I recall there were some discussions about this for value aliases, but I
>> don't remember the conclusion.
>
> I'd like us to specify that they compute to the corresponding
> CSS values, so your example would print "vertical-rl".
>
> This allows the UA to treat them as aliases early in the parsing
> process, rather than having to maintain separate values
> throughout, and reinforces the fact that they behave exactly the
> same rather than perhaps having some subtle (even unintentional)
> difference.

I would love to do this. However the SVG spec does prescribe some
obscure differences in behavior for its right-to-left values (which,
might it be pointed out, do not affect bidirectional ordering).
See "inline-progression-direction" in
   http://www.w3.org/TR/SVG/text.html#TextLayout

I don't quite understand the implications, and I am not sure if it's
important enough that any implementation needs to preserve this
distinction between e.g. 'writing-mode: lr' and 'writing-mode: rl',
but I'll have to defer to the SVGWG on this point.( I'll just note
that when I tested this all a few years ago, implementations didn't
agree on whether it mattered or what it should do.)

SVGWG! Can we compute both 'writing-mode: rl' and 'writing-mode: lr'
to 'writing-mode: horizontal-tb' or do you need to preserve the
distinction?

~fantasai