W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-transforms] translate() vs. translate3d()

From: Aryeh Gregor <ayg@aryeh.name>
Date: Fri, 10 Feb 2012 11:35:55 -0500
Message-ID: <CAKA+Axnx=63eOQu63AnJ6-c4YNqPKpPEY9ySLF4FpOZYjpWi6w@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: Christoph P├Ąper <christoph.paeper@crissov.de>, "www-style@w3.org CSS" <www-style@w3.org>
On Fri, Feb 10, 2012 at 10:27 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> I added the two offset arguments for rotate() yesterday. While for Rotate3d you specify a vector to define the aches around you want to rotate the element in 3d space, rotate() defines an offset to the origin. And you rotate the element around this given point. So it is hard to combine both functions and separating makes more sense then.
> Note that rotate excepts length and percentage, while rotate3d just excepts numbers (vector).

Browsers do not implement this in CSS.  Do they plan to?  I think the
extra arguments are confusing -- they're redundant to
transform-origin, and they aren't present for matrix() or scale*() or
skew*(), where they're equally relevant.  They might have made sense
in SVG, which had no transform-origin, but I don't think they belong
in CSS.  I don't think complicating CSS is a good cost to pay to bring
it more in line with SVG.

Regardless, this kind of thing needs to be decided by implementers.
Do they want to implement the extra two arguments to rotate()?  If so,
then sure, let's keep them.  If not, I strongly feel they should be
removed from the spec.
Received on Friday, 10 February 2012 16:36:57 UTC

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