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

Re: [CSS-transforms] rotate(<angle>[, <translation-value>, <translation-value>])

From: Dirk Schulze <dschulze@adobe.com>
Date: Sat, 18 Feb 2012 14:39:05 -0800
To: Rik Cabanier <cabanier@gmail.com>
CC: Chris Marrin <cmarrin@apple.com>, Aryeh Gregor <ayg@aryeh.name>, "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
Message-ID: <81D01017-1DC7-4CDF-B259-2E241C0914EB@adobe.com>

On Feb 18, 2012, at 1:48 PM, Rik Cabanier wrote:

Hi Dirk,

the problem is not technical. It's about what the user expects to happen so this needs input from authors.
The color transition issue that Aryeh mentioned is a good example where simply doing the math will not give the expected results.
Maybe we need the input from more authors. Nevertheless, the described behavior is logical from the math point of view, as well as from the behavior in my eyes. We shouldn't specify possible abstruse assumptions of authors.

But because you are an SVG guy, here is an example with SVG animation:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect width="100" height="100" fill="green">
    <animateTransform attributeName="transform" type="rotate" to="45 200 200" dur="3s" fill="freeze"/>

Same situation: no start value specified, but 'to' has three arguments. Compare it in every browser you want (beside IE which doesn't support SMIL), you get the same result in every browser. The rotation starts from rotate(0 0 0) and goes to rotate(45 200 200). And even with  from="0", you still get the same result. I wouldn't expect something different. It would be strange if CSS Animations behaves differently (and against assumptions of authors in my eyes).

I read the new definition of rotate:
specifies a 2D rotation<http://dev.w3.org/csswg/css3-transforms/#RotateDefined> by the angle specified in the parameter about the origin of the element, as defined by thetransform-origin<http://dev.w3.org/csswg/css3-transforms/#transform-origin> property, or a given point as to the origin of the element.
This doesn't sound correct. Are you replacing the transform-origin with the new value?
I was under the impression that it was simply doing the translate(a, b)/rotate/translate(-a,-b). Undoing the transform-origin introduces a lot more math.
No, transform-origin should not get reset. If you interpret it that way, the text needs to clarify it more. The result should be as you would expect: translate(a, b)/rotate/translate(-a,-b).



On Fri, Feb 17, 2012 at 10:06 AM, Dirk Schulze <dschulze@adobe.com<mailto:dschulze@adobe.com>> wrote:
I really don't understand the problem here? The default values for the optional arguments are 0,0. So if a developer wants to animate to (45deg, 10px, 10px), why would he expect that the rotation is around 10px,10px? If he would expect that, he would specify the 'from' as well.

The same for translate

 from{ transform: none}
 to{ transform: translate(20px,20px); }

Why should the author expect that the animation starts from (0, 20px), just because he took none for 'from'? The default is (0,0). Same for scale where the second argument is 1, for skew it is 0. Why should authors expect that the optional arguments for 'none' are the same like specified for 'to'?


On Feb 17, 2012, at 9:52 AM, Chris Marrin wrote:

> On Feb 17, 2012, at 7:59 AM, Aryeh Gregor wrote:
>> On Thu, Feb 16, 2012 at 5:14 PM, Dirk Schulze <dschulze@adobe.com<mailto:dschulze@adobe.com>> wrote:
>>> Well, the initial value would be rotate(0,0,0). Therefore no. If you want to
>>> always have the animation around (10,10) , you would need to define it in
>>> 'from'.
>> I suggest that if the extra two arguments are left in the spec (which
>> I'm still not a fan of), an extra special case be added to the
>> transitions part so that it works as expected.  Transitioning from
>> 'none' to rotate3d(0, 0, 1, 45deg) rotates only around the z-axis as
>> expected, and transitioning a color from green to transparent
>> shouldn't make it black in between even though you're technically
>> going from rgba(0, 128, 0, 1) to rgba(0, 0, 0, 0).  Likewise,
>> transitioning from none to rotate(45deg, 10px, 10px) should be treated
>> like transitioning from rotate(0deg, 10px, 10px).  Anything else is
>> not expected, IMO.
> And that, I think, is the problem with having origin parameters in the rotate function. In rotate3d, the axis and angle are inseparable. You need both to have a complete description of a rotation. That's not the case for the origin parameters in the rotate() function. rotate(45deg, 10px, 20px) is simply shorthand for translate(10px, 20px) rotate(45deg) translate(-10px, -20px). If I transitioned from none to translate(10px, 20px), I'd start at 0,0. Special casing the translation values embedded in the rotate function seems strange.
> -----
> ~Chris
> cmarrin@apple.com<mailto:cmarrin@apple.com>
Received on Saturday, 18 February 2012 22:39:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:28:39 UTC