Csswg-drafts: [css-transforms-2] Please remove from drafts: scale, translate, rotate CSS style etc.

[Nadya678]

Example:

transform:scale(2) translate(50px,50px);
transform:translate(50px,50px) scale(2);

THERE ARE TWO DIFFERENT TRANSFORMS. It cannot be separated to scale and translate.
Living demo: https://jsfiddle.net/p7sb1o6h/
If there will be the same transform, the red and blue rectangle shall be in the same visual position.

The scale, translate, rotate etc. styles (not transforms) shall be removed from all drafts.

The

{
   transform:scale(-1) translate(50px,50px);
}

cannot be translated to:

{
   scale:-1;
   transform:50px 50px; 
} 

transforms are made in order in which they was defined.
What is order of transformations in this case?

{
   scale:-1;
}
html div
{
   transform:50px 50px;
}

[astearns]

transforms are made in order in which they was defined

This is incorrect. The order in which everything is applied is defined in https://drafts.csswg.org/css-transforms-2/#ctm

But perhaps this could be pointed out in the section defining the individual transform properties (replacing the current "Fluff here" text).

[Nadya678]

"Reinvent the wheel" antipattern...

[birtles]

One of the purposes of these properties is two provide a consistent order for combining the different types of transforms, rather than having to manage the list of transform functions oneself. This is particularly useful when animating the individual components independently. Without this, to achieve the same effect the author would require either additional wrapper elements, or additive animation with careful control of the composite order.

Animation libraries such as GreenSock animation also do this (although GreenSock further separates out x/y components).

Applications that require a different order to that defined for these properties can continue to use the transform property. That is, these properties are not intended to entirely replace the transform property but at the same time they enable use cases not possible with transform.

[AmeliaBR]

I agree these properties are very useful, for the reasons @birtles stated, and would not want to see them removed. But I think they can also be confusing for the reasons given in @Nadya678's issue.

A few clarifications to the section defining the properties could help:

• As @astearns mentioned, there should be a description of the order in which the three properties are applied, with a link to the section on the Current Transformation Matrix

• There should also be a note clearly stating that these are _not_ longhands for the transform property, and that they do not replace any transformations specified with that property.

• As mentioned in #2109, there should be some sort of explicit statement about which values trigger 3D transformation mode.

It would probably also be useful to have an example showing how they can be used to apply multiple independent transformations. E.g., how it allows you to add a :hover { scale: 1.1; } rule on a class of elements that already have (possibly unique) translations or rotations.

[FremyCompany]

I would prefer we kept them.

I wouldn't mind, though, if we limited them such that they cannot be used with preserve-3d nor any 3d effect. That would make them more intuitive, to my humble opinion.

[EDIT: This is however a different topic; we discussed this in the scale issue and @tabatkins had a good point saying that if you work in full 3d, these properties make as much sense as they do in 2d, it's just a matter of not mixing 3d transforms in 2d content or 2d transforms in 3d content by accident]

[css-meeting-bot]

The Working Group just discussed [css-transforms-2] Please remove from drafts: scale, translate, rotate CSS style etc., and agreed to the following resolutions:

• RESOLVED: no change with clarification notes from the issue

The full IRC log of that discussion

<dael> Topic: [css-transforms-2] Please remove from drafts: scale, translate, rotate CSS style etc.

<dael> github: https://github.com/w3c/csswg-drafts/issues/2126

<dael> ericwilligers: They are valuable. They have the full motoin path and can be independantly animated.

<dael> ericwilligers: I think libraries will find it useful.

<Rossen_> tsr ftw

<dael> TabAtkins: They also let us capture the generally most intuitive ordering without making authors remember it. translate then scale then rotate

<dael> AmeliaBR: They's useful for [missed]

<TabAtkins> +1 to all that AmeliaBR is saying too.

<dael> AmeliaBR: They're useful for animations, you can animate one factor. And they're useful for different transformations assigned with different classes or pseudo classes

<dael> ericwilligers: There's an issue about preserve 3d from fremy but I think that's a different issue.

<dael> fremy: Feel free to disregard mine.

<dael> ericwilligers: Can we resolve to keep properties?

<dael> Rossen_: fremy you said you have your point in the issue...disregard it? Is that what you wanted?

<birtles> The very popular GreenSock Animation (GSAP) also takes this approach of a fixed order of transform components and promotes it as one of its key usability benefits over CSS (although it further breaks these components into x/y/z too)

<dael> fremy: I agree it's a different issue and shouldn't be in that topic.

<fantasai> +1 to smfr

<dael> smfr: I don't think anybody on this call agrees with the issue. I think we're all okay with separate properties.

<dael> AmeliaBR: I did have a couple comments in there suggesting clarifications in the spec.

<dael> Rossen_: Does anyone support the issue to remove?

<dael> Rossen_: Obj to resolve no change?

<dael> fantasai: No change add clarifying notes.

<dael> Rossen_: Are the notes in the issue?

<dael> fantasai: Yes.

<dael> Rossen_: Obj to no change with clarification notes from the issue?

<dael> RESOLVED: no change with clarification notes from the issue

[tabatkins]

Per the above resolution, we're keeping the individual transform properties.