Bug 166941 – Implement writing-mode: sideways-rl; and sideways-lr;

• Component: Text
• Status: NEW

[Myles C. Maxfield]

See https://24ways.org/2016/css-writing-modes/ and http://labs.jensimmons.com/#writing-modes

[Myles C. Maxfield]

Hyatt says that we currently have the infrastructure to do this quite easily, so the bulk of the work would be to hook up the new properties.

[Myles C. Maxfield]

Hyatt says that these would probably best be implemented with two independent properties: one for line direction which could be rl, tb, and bt, and one for line orientation, which could be normal or flipped. Then writing-mode would be a shorthand for combining these two.

[Myles C. Maxfield]

Hyatt says 1-2 days of work

[Gérard Talbot (no longer involved)]

'sideways-rl' and 'sideways-lr' are at-risk in the latest CR spec 

https://www.w3.org/TR/css-writing-modes-3/#block-flow

and have been removed from the editor's draft

https://drafts.csswg.org/css-writing-modes-3/#block-flow

which lead me to say that supporting 'sideways-rl' and 'sideways-lr' is NOT required in order to claim compliance with CSS3 Writing Modes spec. In all fairness, P2 in this bug report does not seem justified in my opinion.

[r12a]

Implementation of writing-mode: sideways-rl and sideways-lr is still needed.

People are regularly trying to achieve the desired result (and even teaching others to do it) using the other writing-mode properties, even though such an approach only works in extremely limited circumstances and may lead to breakage unless carefully controlled.

CSS Writing-modes 4 is in CR, and was this feature was split from level 3 in order to release what was already available for the benefit of CJK users, however the idea was that these values would be also implemented soon.

It's a feature that plenty of people will benefit from, so can we move up the implementation if it's so straightforward?  (It's already implemented by Gecko.)

[Theresa O'Connor]

This is being tracked by the W3C I18N folk in https://github.com/w3c/eurlreq/issues/11

[Radar WebKit Bug Importer]

<rdar://problem/81519211>

[Tim Nguyen (:ntim)]

*** Bug 150820 has been marked as a duplicate of this bug. ***

[Tim Nguyen (:ntim)]

This is now in writing-modes-4: https://www.w3.org/TR/css-writing-modes-4/#block-flow

[Tim Nguyen (:ntim)]

*** Bug 208075 has been marked as a duplicate of this bug. ***

[Tim Nguyen (:ntim)]

This needs splitting the concept of writing-mode from typographic mode in the WebKit code.

[Tim Nguyen (:ntim)]

Text direction (rtl/ltr) also needs to be decoupled from inline base direction.

[Tim Nguyen (:ntim)]

I started some work here: https://github.com/nt1m/webkit/tree/sideways-wm

sideways-rl is working well, sideways-lr is the harder one, since font-orientation needs to be rotated on the other side, in addition, inline direction is wrong atm.

[r12a]

W3C is tracking this bug report at https://github.com/w3c/eurlreq/issues/11

[Simon Fraser (smfr)]

Need to fix imported/w3c/web-platform-tests/css/cssom-view/scrollIntoView-sideways-lr-writing-mode-and-rtl-direction.html, which is reporting a negative scrollLeft

[r12a]

I'm surprised by the comments about decoupling directional features, font orientation, etc.  I think that the point it that everything works as normal except that the box is rotated either to the left or right.  We still want the start/end points to be the same, the line wrapping to be the same, and the font glyph orientation to be the same, if you were to then unrotate the box.  That's the distinguishing feature about the sideways values compared to the vertical-lr and vertical-rl options.