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: Dean Jackson <dino@apple.com>
Date: Wed, 16 Jul 2014 11:29:23 +1000
Cc: Dirk Schulze <dschulze@adobe.com>, www-style list <www-style@w3.org>
Message-id: <6CB3CB6F-8618-49F5-8C44-1B8716186404@apple.com>
To: Shane Stephens <shans@google.com>

> On 16 Jul 2014, at 11:13 am, Shane Stephens <shans@google.com> wrote:
> FWIW I oppose this proposal as well. I think it will be more confusing, if *only* because people will have to remember the transform order. I understand that some people will think it is simpler, because in their cases they will only need to write one of the functions e.g. rotate.
> I think this proposal will be *less* confusing, based on the experience of library vendors like GSAP.

So, which of the following is less confusing?

A. transform applies the list of functions in the order they are written.

B. You can write all of the core 21 transform properties in any order you like, as well as a transform longhand, to create a transform-list value. The individual properties are combined in the order of ...... well, translates happen before scales, which happen before rotations... and 2d things happen before 3d things (even if the 3d thing is really just a 2d thing), and Xs come before Ys come before Zs (or do they, since rotateZ is just 2d??), and perspective... I guess that comes last. Skews, they come... somewhere. Oh, but if you put a transform in there, it will reset all of the individual properties that came before it. And if you put individual ones after the transform, then it will .... I guess it won't reset the transform because then it wouldn't be like normal longhands, so maybe it adds to it? But I'm now not sure if the individual ones apply before the transform rule or after it.... OMG.

> Lastly, I think transforms have been a pretty huge success, as have animations. I'm not sure this syntax issue is holding anyone back.
> Transforms and animations have been successful because they let developers do something they couldn't do before - use a different thread to the UI thread for animation.

Yes, but that's not the only reason. The other reason is they are simple to understand.

> Don't confuse successful with well-designed or even feature-complete.

I think I'm able to make the distinction. I think gradients are a better example of successful despite being badly designed - hence all the tools to create the syntax.

I think transforms are well-designed. Like I said, the behaviour is understandable in one sentence. What's being proposed here is a change in syntax and behaviour to address a particular use case. I think we're confusing the simplicity of the content (I just want to apply a rotation) with the hope that it will be an equally simple change in behaviour. It's not.


Received on Wednesday, 16 July 2014 01:29:58 UTC

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