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

On Wed, Jul 16, 2014 at 1:58 PM, Dean Jackson <dino@apple.com> wrote:

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

OK, I think this is the crux of the misunderstanding. In the general case,
components of a transform list have an effect that is dependent upon the
components that have preceded them. So for example, a translate(100px) will
actually translate by (70px, 70px) if preceded by a rotate(45deg).

However, there's an ordering for which this dependency doesn't occur.
Taking just rotate and translate, for example, performing the rotation
after any translation has the same local effect as performing the rotation
alone. The proposal uses this order.

So when we talk about 'order dependency', this is what we mean - that a
translation in X can turn into a translation in X and Y if preceded by a
rotation, or that a simple scale and rotate can turn into a skew if applied
in the wrong order.

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

No, I think you misunderstand. However, the proposal *is* all or nothing
for each component, and each component acts independently of the others, so
it's very similar but more flexible.


> 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 think the latest version of the proposal doesn't reset anything -
transform applies after whatever is specified in rotate, translate, and
scale.

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

This isn't true, and I think it's based on misunderstanding what we mean by
order dependency.

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

The decomposition order has the property that each component is now
independent of those that precede it. It means that if the matrices were
chosen based on a desire for a translation to a screen location, a rotation
around the local origin of the component, and a scale centered around the
same local origin, then the resulting decomposed components will animate
sensibly. I assume this choice was deliberate, but if not it was felicitous
:)

Cheers,
    -Shane