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

On Tue, Jul 15, 2014 at 5:49 PM, Dean Jackson <dino@apple.com> wrote:
>> On 12 Jul 2014, at 4:22 pm, Dirk Schulze <dschulze@adobe.com> wrote:
>>
>> While I acknowledge that it can happen that one writes translate: … or rotate: … accidentally, it is a mistake that can be figured out very quickly. Solving this is over engineering IMO. I am opposed to this proposal.
>
> 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.
>
> However, do you think a new developer would instinctively know what happens here?
>
> el {
>   rotate: 10deg;
>   transform: rotate(-20deg);
>   translate: 10px;
> }
>
> 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?)

Actually, that example will probably do what's expected - the element
will get rotated -10deg total, and also translated 10px in the x
direction.  At least for translate and rotate, I think the default
ordering is exactly what people expect "independent" properties to do.
(And scale and skew, in their default position, also do what would be
expected from "independent" properties.)

Since the other properties don't really have a "natural" composition,
let's try cutting the proposal down to just these:

* translate: x y? z? (becoming a translate3d() function)
* rotate: angle number{3}? (becoming a rotate3d() function, defaulting
to the "0 0 1" axis)
* skew: x y (becoming separate skewX() and skewY() functions)
* scale: number number? number? (becoming a scale3d() function)

This gives you all the basic functionality of transforms in four
independent properties, and puts them together in a way that *acts*
like their effects are actually independent in an intuitive way.

(We *might* want to consider skew an advanced transform, like Dirk
says, and just leave it out. We wouldn't lose much from that.)

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

I believe it does, at least within the bounds of what I said above.
There is a particular ordering of translate/rotate/skew/scale that
makes them look like they're independent.

> Longhands create a lot of authoring confusion, due to resetting.

I assume you mean shorthands.  CSS is infested with them, so authors
better get used to them.  But we can also reduce the effects of this,
as I describe above.

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

Additive transforms are far more complicated to make work well than
you imply here.  I agree that we want additive animations, but for
decent usability, we still need to solve the list-valued properties
problem.  As I said in earlier emails, while this proposal doesn't
solve that problem fully, it covers most of the useful stuff for
'transform'.

> Lastly, I think transforms have been a pretty huge success, as have animations. I'm not sure this syntax issue is holding anyone back.

What Shane said. ^_^

~TJ

Received on Wednesday, 16 July 2014 01:30:37 UTC