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

On Wed, Jul 16, 2014 at 11:29 AM, Dean Jackson <dino@apple.com> wrote:

>
> 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.
>

You might find this hard to believe, but many web developers find it really
confusing that

transform: 'translate(100px) rotate(45deg)'

and

transform: 'rotate(45deg) translate(100px)'

do different things. In other words, A significantly under-represents the
confusion inherent in transform lists.

Your option B would be better expressed as:

B: Just like every other CSS property, expressing transform components
works the same regardless of which order they're expressed in, and each
component acts independently of the others.

Although I agree that this doesn't take into account how the 3D and 2D
variants interact, and we probably need to do something nice there.

>
>> 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.
>

Except that they aren't. People get seriously confused by the fact that
transform lists are order-dependent.


> 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.
>

The transform specification does a reasonable job of directly presenting a
complex topic (matrix-based manipulation of transforms). It doesn't do
anything to help authors understand this complex topic, which is part of
what Tab is trying to do. So, no, the behavior isn't understandable in one
sentence - only the *mapping* is.

Cheers,
    -Shane