[fxtf-drafts] Logical Transforms

majido has just created a new issue for https://github.com/w3c/fxtf-drafts:

== Logical Transforms ==
## Problem

Currently transform only defines physical properties e.g., translate and scale work on x and y ignoring block or inline axis and writing-mode and direction. 

CSS defines a set of logical (longhand?) properties to allow web developers to create layout that are correct regardless of the writing mode. The fact that transform lack these makes them awkward to use them in conjunction with logical properties to create writing mode independent layout and animations.

See for example [this article](https://rtl-css.net/tutorial/quick-tip-rtling-css3-transform-functions-translate-and-translatex) to see how developers currently use transforms in such context. Another example is [RTLCSS](https://github.com/MohammadYounes/rtlcss) which seems to be a popular  style preprocessor tool used to get around this shortcoming. 

I propose we add logical long-hand for transform properties.

Here is a [simple demo](https://codepen.io/majido/pen/ePPvbZ?editors=1100
) that shows the current behavior and what I consider the ideal logical behavior of transform when writing mode is changes.

BTW RTLCSS has a playground where you can paste 

```css

.example {
   direction:ltr;
   transform: translate(100px, 200px) scale(2.0, 1.0) rotate(25deg);
   transform: translate3d(100px, 200px, 300px);
}
```
and it turns into 

```css
.example {
   direction:rtl;
   transform: translate(-100px, 200px) scale(2.0, 1.0) rotate(-25deg);
   transform: translate3d(-100px, 200px, 300px);
}
```

Transforms are popular for animations due to their performance benefits. So this issue is particularly problematic for animations.

Another related issue is that as we have been working on introducing scroll-linked animations (which can operate based on logical or physical directions), it [seems most natural](https://github.com/WICG/scroll-animations/issues/23) that a logical ScrollTimeline should be used to drive logical properties. So having logical transforms is desired. This is why we originally started looking into this.

## Proposal

Introduce logical syntax for transform where various 2d components can be
specified in terms of logical values such as inline base and block flow direction.

These logical values can then be [mapped](https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical) to appropriate physical values similar to other logical properties.



## Syntax ideas 1 

Perhaps we can have logical version of 2d transform functions e.g.,
`translate-logical(inline, block)` === `translate(x, y)`
`scale-logical(inline, block)` === `scale(x, y)`

Also individual transform for inline, block matching translate{X,Y} and scale{X,Y}

Similarly introduce a logical version of transform origin
`transform-origin-logical: inline block` === `transform-origin: x y`

This seems close to what other logical properties have. 

For the shorthand, we can allow both physical and logical versions to be mixed in transform function list.
This also provides a nice way to have backward compatibility e.g.:

```css
.myclass {
  transform: translate(-100px, 50px) scale(2); /* This is assuming direction: rtl */
   transform: translate-logical(100px, 50px) scale(2); /* New syntax overrides in new implementations */
}
```
## Syntax idea 2
Perhaps we can have a mode:

`transform-mode: logical; /* defaults to physical */`

Although based on my understanding CSSWG seems to prefer to avoid designs that introduce modes.

# Other considerations

- What should happen to rotate?
For rotation we can have define the rotation direction that relies on the  inline and block arrows relationship. I suspect this may actually be meaningful since this is what the RTLCSS appears to be doing. Alternatively we can leave the rotation to remain consistent regardless of writing mode.

- What about 3d transform functions?
Z axis does not have a logical equivalent so it should be left alone. Given this, it is not clear if we need to have logical version of 3d transform functions.

- How should this specified?
We suspect that this does not require a whole lot of change to the specification. In particular, we may be able to do this by introducing a matrix that represent the logical to physical mapping and simply do a matrix multiplication as the last step to change logical into physical. Obviously a closer look is needed to actually confirm this is possible.

- Performance implications
Writing modes are not expected to change very often so we don't expect this to be a lot different than recalculations that needs to happen to resolve percentage and calc values. Browser fast path could still continue to operate on physical basis.


Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/311 using your GitHub account

Received on Tuesday, 23 October 2018 23:24:58 UTC