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

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


> However, do you think a new developer would instinctively know what
> happens here?
>
> el {
>   rotate: 10deg;
>   transform: rotate(-20deg);
>   translate: 10px;
> }
>

Ignoring the 'transform' component for a minute:

el {
  rotate: 10deg;
  translate: 10px;
}

This does exactly what you would expect - treating rotation and translation
as separate channels, it rotates by 10 degrees and it translates in the X
direction by 10 pixels. So does this:

el {
  translate: 10px;
  rotate: 10deg;
}

That's the point of the resolution order Tab has suggested. In particular,
this neatly avoids the surprise many new developers encounter when they
specify a transform property with the components in the 'wrong' order.

Mixing transform component properties and a transform property should be
considered an advanced use, and at any rate is no more complex than the
transform property already is.

>
> That is certainly not simple. (And if you're not going to include all the
> 3d forms, then people will likely get into these situations... and if you
> do include them, does rotateY come before or after rotateX? - How do you
> remember the order of everything?)
>

I agree that we need sensible behavior for how the 3D and 2D properties
interact.

"How do you remember the order of everything?" - it's just normal CSS
resolution, isn't it? This doesn't seem like it's an issue.


>
> Furthermore, the platonic property you're trying to modify is the
> transform. It's really all or nothing (with the disappointing issue of
> transform-origin as a pre+post transform). Splitting it up into
> sub-properties doesn't make sense. Longhands create a lot of authoring
> confusion, due to resetting.
>

Splitting up the transform property into non-interacting translation,
rotation and scale components has been a pretty big request from web
developers (again, as demonstrated by libraries like GSAP). It is true that
doing this is less general than a transform property - but it's also much
simpler to reason about, especially if you've never encountered non-abelian
groups before. The beauty of Tab's proposal is that we can do both.


> Tab's impossible example is much better solved by allowing additive CSS
> animations i.e. two independent animations on the same property to combine
> with either addition or multiplication.
>

Once you bring additive CSS animations into the mix, being able to add
animations on individual transform components again gives you a set of
abilities that you can't do with a single transform property - for example
having multiple animations contribute to a translation on the screen
without impacting the rotation or scale of the element.


>
> 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. Don't confuse successful with well-designed or even
feature-complete.

Cheers,
    -Shane