Re: [css-writing-modes] computed value for text-orientation: sideways or sideways-right

On Fri, Sep 18, 2015 at 2:14 PM, Florian Rivoal <florian@rivoal.net> wrote:
>
> On 18 Sep 2015, at 12:52, 馬場孝夫 <baba@bpsinc.jp> wrote:
>
> If we use 'sideways' as the computed value for 'sideways-right', 'sideways'
> has to mean rotate 90° clockwise. I think this makes two problems in future:
>
> (1) We cannot use 'sideways' for auto-switching mechanism according to
> 'writing-mode' (like original intent of the spec).
>
> This is true, but I don't think it matters, because the auto-switching
> mechanism
> was only needed for the horizontal-script-used-as-a-vertical-caption, which
> is
> now better served by using the two new writing modes.

Yes, auto-switching mechanism is not really needed if we have 'writing-mode:
sideways-lr/rl'.

However, personally I can not really agree to those new writing-mode values.

Everything which is become possible by 'writing-mode: sideways-lr/rl' is also
able by 'writing-mode: vertical-lr/rl' + 'text-orientation:
sideways-right/left'.

If we reintroduce 'text-orientation: sideways-left' in future, those new
writing-mode values are no longer needed.

In my opinion 'writing-mode: sideways-lr' is not really needed just now
because it can be roughly replaced with 'transform: rotate'; therefore,
'writing-mode: sideways-lr/rl' should be dropped.


> (2) Both 'sideways' and 'sideways-right' means rotate clockwise, while
> 'sideways-left' means counter-clockwise (as following list). It is
> asymmetric
> and looks weird.
>
> - sideways-right: computed to 'sideways'
> - sideways-left: rotate counter-clockwise
> - sideways: rotate clockwise
>
> sideways-right is not longer needed, except for compatibility with
> legacy content. And I am not sure we actually have that much legacy
> content specifying sideways-right unprefixed. I'd be in favor of dropping it
> if we can.
>
> And if we ever need to reintroduce the behavior of the sideways-left value,
> which is far from certain, we can be creative on the naming then, and I
> would not have an issue with that name being longer, since it is a less
> frequently used value.

Do you mean that the values should be arranged like below?

- 'sideways-right': [dropped]
- 'sideways-left': [dropped]
- 'sideways': rotate clockwise
- new value such as 'sideways-reverse': rotate counter-clockwise [future level]

If this my understanding is true, it seems to be consistent.
However, since I think auto-switching mechanism is still needed as I wrote in
above, I feel the original keywords look better.

Baba

----------------------------------------------------
ビヨンド・パースペクティブ・ソリューションズ株式会社
〒160-0023
東京都新宿区西新宿6-20-7 コンシェリア西新宿TOWER'S WEST 2F
Tel: 03-6279-4320 Fax: 03-6279-4450
http://www.bpsinc.jp
馬場 孝夫（Baba Takao）


On Fri, Sep 18, 2015 at 2:14 PM, Florian Rivoal <florian@rivoal.net> wrote:
>
> On 18 Sep 2015, at 12:52, 馬場孝夫 <baba@bpsinc.jp> wrote:
>
> If we use 'sideways' as the computed value for 'sideways-right', 'sideways'
> has to mean rotate 90° clockwise. I think this makes two problems in future:
>
> (1) We cannot use 'sideways' for auto-switching mechanism according to
> 'writing-mode' (like original intent of the spec).
>
> This is true, but I don't think it matters, because the auto-switching
> mechanism
> was only needed for the horizontal-script-used-as-a-vertical-caption, which
> is
> now better served by using the two new writing modes.
>
> (2) Both 'sideways' and 'sideways-right' means rotate clockwise, while
> 'sideways-left' means counter-clockwise (as following list). It is
> asymmetric
> and looks weird.
>
> - sideways-right: computed to 'sideways'
> - sideways-left: rotate counter-clockwise
> - sideways: rotate clockwise
>
> sideways-right is not longer needed, except for compatibility with
> legacy content. And I am not sure we actually have that much legacy
> content specifying sideways-right unprefixed. I'd be in favor of dropping it
> if we can.
>
> And if we ever need to reintroduce the behavior of the sideways-left value,
> which is far from certain, we can be creative on the naming then, and I
> would not have an issue with that name being longer, since it is a less
> frequently used value.
>
>  - Florian
>
>
>

Received on Saturday, 19 September 2015 01:32:18 UTC