Bug 166941 (sideways-lr)

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.

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.

Hyatt says 1-2 days of work

'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.

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.)

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

<rdar://problem/81519211>

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

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

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

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

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

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.

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

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

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.

Created attachment 473760 [details] sideways-lr form controls

Created attachment 473761 [details] sideways-lr form controls

Created attachment 473762 [details] sideways-rl form controls

Test imported/w3c/web-platform-tests/css/css-writing-modes/table-column-order-slr-007.xht has been consistently passing in all platforms since https://commits.webkit.org/288447@main so removing from TestExpectations.