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

> On 16 Jul 2014, at 12:21 pm, Shane Stephens <shans@google.com> wrote:
> 
> 
> Do you realise that the proposal requires the same level of understanding?
> 
> Yes, I realize that fully understanding every part of the proposal and its interaction with existing transforms requires the same level of understanding. That's different to being able to use Tab's new properties though.

My point was that even if there were only the properties in the proposal and no existing transform property, people would still need to understand transform ordering. The proposal defines an order. You need to understand what that will do.

> 
> It's very fortunate indeed that people don't need to fully understand every part of the box model in order to effectively use CSS...

In the same message you suggest I'm putting forward a straw man, you try to make a point with something at best tangentially related? Anyway, they do need to understand fundamentals like the difference between positioning, margins and padding.

>  
> 
> Now they'll be confused that
> 
> rotate: 45deg;
> translate: 100px;
> 
> and
> 
> transform: rotate(45deg) translate(100px);
> 
> do different things.
> 
> They might be, in which case they'd happily go back to just using rotate: and translate:.
>  
> People need to understand the ordering of transforms. I don't see why you think that's going away. They used to teach LOGO/Turtle to 5 year olds.
> 
> I completely disagree. Many people already *don't* understand this ordering. And for much of what we use transforms for on the web today (e.g. animation of positioning and scaling), we don't *need* to - or wouldn't, if we provided more affordances than a single transform list.

Again, they are going to have to understand ordering. I'm not sure why you are suggesting that the proposal makes this any different.

I agree that the proposal will provide some affordance to do some things in an easier way. The most obvious is an element with a single transform function, in which case this is a small syntactic saving. My problem is the cost of that saving.

>  
> Also, I believe it is a pretty limited view to think that people always want to translate before rotation. Sometimes you pick your heading and travel in a straight line (means you don't have to do trigonometry to place yourself on the circumference of a circle pointing outwards). Other times you want to move in a straight line and then orient yourself in space.
> 
> That's a straw man. We want to keep the transform list for precisely these cases.

In order for this to be a straw man I would have had to misrepresent your views. Maybe you believe I did that when I said "always"? I was referring to the assumption of order in the proposal. In which case, replace that with "more often".

All I stated was that there are common reasons for both types of ordering (even limited to just rotations and translations, ignoring scale), and that it is not clear which should be preferred. Consider putting 8 arrows at the marks on a compass, for example. Half of them are easy with the proposal. The other half would either require trig or the shorthand. And I think this highlights the point that people need to understand the ordering, so that they know when to use the shorthand. (Also, isn't it a bit weird that a shorthand is more powerful than a combination of longhands?)

Anyway, I feel like we've expressed our positions, and there probably isn't much more technical to discuss.

Dean