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 18:56:20 -0700
Message-ID: <CAAWBYDCAbWRVhzEdMwe0xY23_bxWeTzcrR4v12zmtMcmi+JJXg@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: Dirk Schulze <dschulze@adobe.com>, www-style list <www-style@w3.org>
On Tue, Jul 15, 2014 at 6:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Since the other properties don't really have a "natural" composition,
> let's try cutting the proposal down to just these:
> * translate: x y? z? (becoming a translate3d() function)
> * rotate: angle number{3}? (becoming a rotate3d() function, defaulting
> to the "0 0 1" axis)
> * skew: x y (becoming separate skewX() and skewY() functions)
> * scale: number number? number? (becoming a scale3d() function)
> This gives you all the basic functionality of transforms in four
> independent properties, and puts them together in a way that *acts*
> like their effects are actually independent in an intuitive way.
> (We *might* want to consider skew an advanced transform, like Dirk
> says, and just leave it out. We wouldn't lose much from that.)

Some testing shows that the skews *are* order dependent, and there's
not an obvious answer for which order is intuitive.  Let's leave
'skew' out then, and stick with just 'translate', 'rotate', and
'scale', defined as above.  The skew() functions will just be an
advanced feature for 'transform'.

I also forgot about the previous points regarding origins, so let's
put in one for rotate and scale.  This brings us back up to 5

* translate
* rotate
* rotate-origin
* scale
* scale-origin


That out of the way, we can also discuss the 'transform' resetting
behavior.  My original proposal had 'transform-list' as the
independent <transform-list> thinger, with 'transform' as a shorthand
that resets all of them.  Though I think it's slightly less good of a
design, I'd be okay with making translate/rotate/etc *not* get reset
by 'transform', so we don't need a 'transform-list' either.  That
would allow existing uses of 'transform' to mix with new uses of the
new properties without any changes or surprises, at the cost of it
being slightly harder to make everything go back to "normal".  (That
may not be a very important thing.)

Received on Wednesday, 16 July 2014 01:57:06 UTC

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