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: Wed, 16 Jul 2014 07:49:35 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Alan Stearns <stearns@adobe.com>, Dean Jackson <dino@apple.com>, "Shane Stephens" <shans@google.com>, www-style list <www-style@w3.org>
Message-ID: <7A3DB2E0-6219-4801-8C89-01E777BDEBF5@adobe.com>

On Jul 16, 2014, at 8:46 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Jul 15, 2014 at 11:26 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> I think we are back to my original proposed modification. Just three properties: rotate, translate and scale. No shorthands. If we could reduce the proposal to that, it would already be easier to argue since it is more specific.
> Yup, basically.  It was a good idea!
>> This still brings us to the three other problems:
>> 1) Users want to apply an origin.
>> - In SVG, rotate has 3 arguments because of that: angle[, originX, originY]? The rotate() function actually requires it as well in the spec, but it is just partly implemented today.
>> - Tab proposes two new properties to modify the origin for scale and rotate. This already makes it more complex IMO.
> Why do you think it's more complex? It's just copying transform-origin
> for the new properties.

Right, I am saying that the rotate() function already has origin arguments. Why wouldn’t you add them to the rotate property as well and pass on rotate-origin. There have been proposals to add the same support for scale().

>> 2) Fixed order of the new properties and the transform-list.
>> Just take a look at the following examples:
>> http://jsfiddle.net/B3jPX/
>> http://jsfiddle.net/B3jPX/1/
>> - In one example the object rotates around it self (earth around own axis).
>> - In the other example, the translation is used to define the distance from the origin the object is rotated around (earth around sun).
>> Both are very commonly used. In my experience, the second one is mainly used in graphical environments like SVG, the first for responsive designs in HTML. Have a fixed order would leaf out one of the use cases. Adding a new property to define the order, as I proposed, might be an overkill as well.
> Yes, I think it's overkill.  I've come around to the idea that the
> most useful part of this proposal is that the three transforms are
> conceptually independent.  Reordering them is (a) nonsense if they're
> independent, and (b) makes them no longer independent.  If you need to
> do non-independent transforms (like
>> The take away: Even though some stated otherwise: Order matters, as does the understanding what the order means!
> Yes, order matters when you need the transforms to interact.  When you
> don't (when they're all "local"), there's one specific order that does
> what you want.

“local” seems to be confusing here. All transformations are local for an element and take affect on rendering into the parents graphics context. I think what you meant to say is (correct me if I am wrong) that authors most likely just will use one of the transform properties: Either rotate, or translate, or scale or transform. And therefore you just want to have a sane fallback if an author uses them in combination.

If that is the case it would counter your argument about animating one transform set independent of the other in your original proposal. Because if you want to do that, the order matters again to the author and the authors might want to have a different multiplication order of the transform properties. Otherwise, earth-around-sun rotations while doing other transformations at the same time are hard again.

>> 3) rotate, scale, translate are verbs and we don’t use verbs as property names. On the other hand, this would be the thing that makes the properties useful for authors right now. Otherwise authors would need to remember more names and also the rules when which name applies. We probably want to have an exception here and use the verbs instead.
> Yeah, I agree.
>> IMO, I still don’t accept the sentiment that we want to make the easy cases more easier for authors. As Dean mentions, it could be a simplification with a high price and the confusion would move to other parts.
> These cases aren't easy, from author feedback.  That's the point.

It is hard to differ between the cases. I think with this comment you do not refer to the “Ah, I used translate: 20px, 20px instead of transform: translate(20px, 20px)” case, right? Because that is a slip of the pen and can easily be detected and corrected by authors.


> ~TJ
Received on Wednesday, 16 July 2014 07:50:07 UTC

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