W3C home > Mailing lists > Public > www-svg@w3.org > September 2015

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

From: Koji Ishii <kojiishi@gmail.com>
Date: Wed, 23 Sep 2015 22:18:23 +0900
Message-ID: <CAN9ydbVSga3MpqnFZ6jMGpNnrn2tCN=dPpkNkASmw5roBnZbKQ@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: Jonathan Kew <jfkthame@gmail.com>, "www-style@w3.org" <www-style@w3.org>, www-svg <www-svg@w3.org>
On Fri, Sep 18, 2015 at 9:50 AM, fantasai <fantasai.lists@inkedblade.net>
wrote:

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


So this should go to SVG spec rather than CSS spec I guess?

I just checked Blink SVG implementation, and Blink doesn't seem to do
anything different for 'writing-mode: lr' and 'writing-mode: rl'. I'm not
sure serializing value (such as getComputedValue) is used in SVG.

Test: http://jsbin.com/hopaji/edit?html,output

/koji
Received on Wednesday, 23 September 2015 13:19:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:42 UTC