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

> > 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.
>
> 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.
>
> [...]
>
> (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.

I've just been skimming though this thread, and I felt like some of you may 
need to take a step back and look at a more global picture.

Dean, Dirk, you have years of experience with the transformation matrix and, 
it seems, a very mathematical-centered view of 2d/3d transformations. It's 
great, really, but you fail to acknowledge this is a specificity on your 
side and not the general case. The transform property has been designed to 
compliment the mathematical side of the tranformation story and allows a 
bunch of fringe use cases. This is great, but it doesn't represent a 
best-fit for a majority of authors.

I certainly don't consider myself as a noob in 2D transforms [1] and yet 
every time I've to specify both a rotation and a translation, I've to take a 
moment wondering what order I should use. There's a reason for that: we, 
humans, have an intuitive vision of transformations that doesn't quite match 
the mathematical reality. Ask anyone on the street to take a square block, 
"rotate(45deg) and then translateX(10cm)" then repeat with someone else by 
asking to "translateX(10cm) then rotate(45deg)" and I'm pretty confident 
you'll get a similar statistical distribution of outcomes. This is because 
we, as humans, consider transforms as something we do, not something the 
object does. We grab an object, and then transform it. When we speak about 
rotation, we talk about rotating our hand; when we talk about translation 
about moving our whole arm. Those movements are totally independant, there's 
no difference in outcome whatevher the order you use for the operations, and 
this is the point Tab and Shane have been trying to advocate.

I don't think there is something wrong in enabling to specify the basic 
operations in an human-oriented approach using "rotate/scale/translate" 
properties. I think making them apply before any "transform" and just let 
them cascade independently of it could make sense in a series of usual 
cases, especially when animations enter in action.

Best regards,
François


________________________
[1] I followed courses about Linear Algebra & Geometry at the university 
and, even before, I remember doing 3D rotations demos using the DHTML Filter 
Matrix which, as the name implies, only allowed to specify a transformation 
matrix. So, I certainly know what I'm talking about.

Received on Wednesday, 16 July 2014 09:45:21 UTC