W3C home > Mailing lists > Public > www-style@w3.org > July 2014

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

From: Shane Stephens <shans@google.com>
Date: Wed, 16 Jul 2014 13:24:09 +1000
Message-ID: <CAGTfzwS4nUqhk3QtAkbL+TJ=mSFjmE8c8MZKc1_3eFnKEKMC9w@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: Dirk Schulze <dschulze@adobe.com>, www-style list <www-style@w3.org>
> 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.

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

> 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

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.

Received on Wednesday, 16 July 2014 03:24:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:44 UTC