[css-transforms][css-logical] Flow-relative Transforms

[fantasai]

https://lists.w3.org/Archives/Public/www-style/2015Jan/0209.html
Transforms always operate on physically-oriented coords. Should it be possible to have logical transforms? If so, how?

[mirisuzanne]

This is a great idea. While I can think of use-cases where the flow is irrelevant to a transform, I can think of many other cases where transforms are used similarly to relative positioning, and would absolutely be flow-dependent.

I think most of the X/Y transforms could be adapted pretty cleanly from an author perspective: scaleInline(), skewBlock(), translateInline(), etc. Are there some that cause a bigger problem?

[chriskirknielsen]

To follow up: would there then be a translateLogical or rotateBlockInline for 2D transforms that usually follow XY? What about 3D contexts? And matrix?

I think most authors wouldn't mind using the "longhand" by defining each transform logically if it helps keep the code easy to understand, but some might like the convenience they find in translate(Xem, Yem) to be easy to reach for with logical transforms.

Or flip it on its head and use a transform-logical property, and the "shorthands" (anything that doesn't have X or Y) as values. But I don't think people would like to have to use another property.

[tomayac]

I have an app, SVGcode that has an LTR and an RTL layout with hoverable elements that scale up from the corner to the middle at the logical start and end of the inset inline and the inset block. A reduced reproduction case can be found in this demo on Glitch (hover over the avatar).

While I can position the images logically via the CSS below (disregard that this could be achieved with margin as well)…

img {
  position: absolute;
  inset-inline-start: 10px;
  inset-block-start: 10px;
}

…I have to hand-code the transform-origin as follows:

[dir=ltr] img {
  transform-origin: top left;
}

[dir=rtl] img {
  transform-origin: top right;
}

Would it be feasible to make transform-origin respect inline-start/end and block-start/end as values, so that the CSS could look as follows?

img {
  position: absolute;
  inset-inline-start: 10px;
  inset-block-start: 10px;
  transform-origin: block-start inline-end; /* Doesn't currently work */
}

Or maybe I'm overlooking something, in this case sorry for the noise and thanks for a pointer where I could read up upon the current solution.

(Migrated from #7051.)

[clshortfuse]

Having similar issues now that I have changed most of my code to block/inline. I'll share my workaround for horizontal (inline);

:root {
  --transform-inline: translateX(100%);
}
:root[dir=rtl] {
  --transform-inline: translateX(-100%);
}

.element {
  transform: var(--transform-inline);
}

I personally like the transform: transformInline(100%) translateBlock(100%) format. I'm not sure if we are able to detect vertical (block) writing mode, so I'm not sure how to workaround this without Javascript. If there isn't a way to do this with pure CSS, then I think we should add a new transform rule.

[aderchox]

I've encountered this and for now I've used a workaround similar to @clshortfuse's (by reading the direction and passing it as a prop to the styled component), but I hope in the future we'll have logical transform properties and values too.

[nico3333fr]

Yes, there are some cases where we would really need this, I'm facing one right now for a custom toggle (using transforms for smooth animations):

LTR:

I'm doing:

transform: translateX(<value>);

for active state.

But it will give this in RTL:

I have to do:

transform: translateX(-<value>);

To get the proper display:

Something like: translate-inline-start or something else would replace something like:

[dir="rtl] .selector {
transform: translateX(-<value>);
}

And same for translateY, we would go for translate-block-start.

For translateZ, I guess i18n does not encounter negative 3D written stuff... so it's okay :D

Migrated from #1788

[thibaudcolas]

Does anyone involved with the standardisation process know how this could be taken forward? It’s surprising to me that this issue has been opened for so long, and also heartening to see so much recent activity. With browser support for logical properties and values getting pretty good, I can only imagine lots more people will start to be looking for this for transforms too.

---

Sharing my personal flavour of a workaround in case it helps – essentially using the same technique as for icons mirroring:

:root {
    --flow-direction: 1;
}

[dir="rtl"] {
    --flow-direction: -1;
}

.classname {
  transform: translateX(calc(var(--flow-direction) * 100%));
}

Bit verbose but makes it possible to use this --flow-direction custom property in all sorts of calculations, and override it per-component for pages displaying multiple languages.