W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-transforms] Making 'transform' match author expectations better with specialized 'rotate'/etc shorthands

From: Dirk Schulze <dschulze@adobe.com>
Date: Sun, 13 Jul 2014 14:04:29 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <8057066F-34E4-4DCA-8469-82C52441CE61@adobe.com>

On Jul 13, 2014, at 5:13 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> transform: <perspective> <translateX> <translateY> <translateZ>
> <rotateX> <rotateY> <rotateZ> <rotate3d> <scaleX> <scaleY> <skaleZ>
> <skewX> <skewY> <skew> <transform-list>;

Not be able to change the order transformations apply is a huge limitation of the proposal. Very often translate and rotate need to change places in the multiplication hierarchy. With a fixed order you are often forced to use ’transform’ anyway. This gets especially clear when you take your ’scale’ example. While I understand that we need independent levels of transformations (to avoid the use of pseudo elements), I am much more supportive to add ‘auto’ and grouping to the transform property than adding more complexity to the platform. (The complexity comes when we speak about the details.)

Furthermore, it is a huge burden to support multiple shorthand “inheritances” (transform <- translate <- translateX) and adding 21 *NEW* CSS properties to implementations. This burden affects performance, memory consumption and therefore everyone.

If we must have new properties to handle author mistakes (not speaking about the current limitations from above that we need to fix anyway) then:

1) Have a default order for applying transformations. Do not introduce short-/ or longhands.
2) Add a property to influence the order of the transformation

	transformation-order: rotate || translate || scale || transform

3) Just expose the most common used transformations as properties:

	scale: <number>{1,3}
	translate: <length>{1,3}
	rotate: <angle>
	transform: <transform-list> 

However, this does not explain how to apply an individual transform-origin for each of the transformation properties. Scale and rotate depend on influencing the transform-origin. This is especially true if you can not use translate(offset, offset) scale(factor) translate(-offset, -offset).

I can just repeat that author mistakes like rotate: 45deg; can easily be detected by authors themselves and therefore don’t require us adding more complexity to the platform.

Received on Sunday, 13 July 2014 14:05:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:44 UTC