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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 15 Jul 2014 20:49:23 -0700
Message-ID: <CAAWBYDA8T78n0G4ZmkXhF8L5RBv6ake+rX3wWiftSy7bH4VQ8Q@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: Shane Stephens <shans@google.com>, Dirk Schulze <dschulze@adobe.com>, www-style list <www-style@w3.org>
On Tue, Jul 15, 2014 at 7:56 PM, Dean Jackson <dino@apple.com> wrote:
> 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.

Yes, this is a great example of a case where it's easiest to treat the
rotate and translate as *not* independent.  That's still completely

> And I think this
> highlights the point that people need to understand the ordering, so that
> they know when to use the shorthand.

Not really.  Whether or not to use the list form is just "are my
translate/rotate/scales independent of each other?".  You don't have
to understand anything about the ordering to answer that question.

(In other words, people are *not* going to be asking themselves "In
this case, should my rotate go before or after my translate?".  Your
brain might be stuck in that mode, because you're so used to
transforms, but most people, myself included, still find the ordering
confusing to think about. ^_^)

> (Also, isn't it a bit weird that a
> shorthand is more powerful than a combination of longhands?)

It's not. That would be completely nonsensical, given the definition
of shorthands, since they disappear entirely during parsing.  In the
transform-as-shorthand version of my proposal, it's the transform-list
longhand that actually does the complicated stuff.  The transform
property just expands into transform-list with the same value and
resets the rest of the transforming properties.

In the transform-as-longhand version I've more recently discussed,
there's nothing weird about it at all, because transform isn't a
shorthand; it retains its current behavior exactly.

Received on Wednesday, 16 July 2014 03:50:10 UTC

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