- From: Dirk Schulze <dschulze@adobe.com>
- Date: Fri, 10 Feb 2012 15:17:55 -0800
- To: Aryeh Gregor <ayg@aryeh.name>
- CC: Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org CSS" <www-style@w3.org>
On Feb 10, 2012, at 8:35 AM, Aryeh Gregor wrote: > 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, That is incorrect. transform-origin applies to a list of transformation functions. With the optional arguments you can specify it for rotate explicitly, independent of the other transformation functions. > and they aren't present for matrix() Well, it doesn't make sense for matrix, no? > or scale*() or > skew*(), where they're equally relevant. I agree in this point. There is/was a bug report about that and I would be open for this change. > They might have made sense > in SVG, which had no transform-origin, but I don't think they belong > in CSS. Like I said, this is independent of transform-origin. Authors use a list of transformation functions quite often. > I don't think complicating CSS is a good cost to pay to bring > it more in line with SVG. I don't think that two _optional_ arguments for the rotation point are more complicated. All existing contents will still work. S you don't have to argue that it will break the web. Also it is used quite often in SVG, so it looks like authors are interested in it. And like I said, this is independent of transform-origin. And also, CSS Transform will be a _merged_ specification between SVG Transform and CSS 2D/3D transforms, why shouldn't we look at SVG? When authors use it on SVG even if they could choose different ways today, why shouldn't CSS authors avoid it? > > 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. I would implement it for WebKit, yes. If there should be a consensus to remove this function, than yes it will be removed again. Greetings, Dirk
Received on Friday, 10 February 2012 23:18:25 UTC