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: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 13 Jul 2014 15:29:27 -0700
Cc: Dirk Schulze <dschulze@adobe.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-id: <2B181C96-08F9-4A4C-8A6A-9F2E22314E19@apple.com>
To: Lea Verou <lea@verou.me>

> On Jul 13, 2014, at 11:04 AM, Lea Verou <lea@verou.me> wrote:
> 
> On Jul 13, 2014, at 17:04, Dirk Schulze <dschulze@adobe.com> wrote:
>> 
>> 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.

It seems like Dirkís limitation #3 would be compatible with this view (maybe a few more functions, but if youíre using the skewX() or matrix3d() transform functions, you are probably no longer doing something simple. To me, it makes sense to handle common simple functions, but adding all 21 seems like overkill if the use case is ease of authoring for simple cases.

If we accept Dirkís #3 above, then doing #1 and #2 (as opposed to solely a predefined order) would not be hard. I donít know enough to know for sure if it would actually be useful. I know that for rotate vs translate, it makes a huge difference which you do first. Though it seems (I have not double-checked the math) that you could always achieve the other effect by rotating the translation vector. So for the simple transform property subset, you probably donít need control over the order.

Regards,
Maciej
Received on Sunday, 13 July 2014 22:29:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC