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

On Jul 13, 2014, at 17:04, Dirk Schulze <dschulze@adobe.com> wrote:
> 
> 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.
> 
> Greetings,
> Dirk

These transform properties are to address really common SIMPLE cases like the ones Tab mentioned. They don’t need to do everything (for more low-level control, there’s always transform-list), so they don’t need that kind of complexity. They don’t need to be able to accomplish everything transform does today, or even a large percentage of it.

~Lea

Received on Sunday, 13 July 2014 18:04:39 UTC