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

> On 16 Jul 2014, at 13:24, Shane Stephens <shans@google.com> wrote:
> 
> > Anyway, I feel like we've expressed our positions, and there probably isn't much more technical to discuss.
> 
> Feel free to ignore this then, but I'd like to address a couple of these points for the benefit of the group.
> 
>> 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.
> 
> This proposal provides a set of properties that don't have order dependency. You don't need to understand that there is order-dependent transform list behavior at all to use these properties. That's the point.

Wait, you're not talking about the proposal then. You're making a new proposal where the author can only set one of the values. If they can set more than one, e.g. rotate AND translate, then there has to be order dependency, right? And an author needs to understand what that dependency means. 

If the proposal was to only set one function, then it becomes a syntactic simplification of swapping transform property with a function name into to a property of the same name. That's fair enough, but doesn't seem like a big deal. After all, another syntactic simplification would be to shorten rotate() to r(), but is it worth it?


>  
>> Again, they are going to have to understand ordering. I'm not sure why you are suggesting that the proposal makes this any different.
> 
> Because if you restrict your usage to translate:, scale: and rotate: you never even need to be aware that an ordering exists. And therefore by definition you do not have to understand ordering.

OK. So you are only (mostly?) concerned about the single function case! If you restrict it to that, then the new properties don't add much confusion, but I think it should be all or nothing - last one wins. i.e. rotate: 10deg is an alias for transform: rotate(10deg). 

This avoids the issues with shorthand properties being reset, and you don't need to choose an order at all. Again, it doesn't seem like much of a benefit, but whatever. 


>  
>> 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".
> 
> That is still a misrepresentation of my views. Here are my views:
> 
> (1) some people understand transform order dependence: and want to do complex things with transform lists. Great!
> (2) some people don't understand transform order dependence (I've met some of them). They would still like to be able to use transforms to move their elements around on the screen. Many of their use cases don't require understanding that order dependencies exist. We should support these people too.

If "moving elements" involves more than one function, there is absolutely no way to avoid understanding order dependencies unless the content happens to be lucky to need the same ordering as the spec has mandated (*). If not, you'll need to use the transform property and understand how the list order works. There are diagrams in the spec. 

[* Aside: choosing the ordering based on what is used in matrix decomposition isn't necessarily a good idea. The decomposition is attempting to extract components in a last gasp effort to make sense out of a raw matrix. It's sometimes correct. ]

> 
>> 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.
> 
> I agree 100%. This proposal doesn't impose a preference on an ordering, but it does provide an affordance for strictly local scaling, rotation and translation of elements, which is awesome.

Since the proposal does impose a preference on ordering (by defining one), I'm again concluding you're talking about a different proposal, and you're limiting to single function cases.

Dean