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

On Sat, Feb 18, 2012 at 2:39 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> 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"/>
> </rect>
> </svg>
>
> 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 the*transform-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).
>
>
Maybe it should read:

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 the *transform-origin*<http://dev.w3.org/csswg/css3-transforms/#transform-origin>
property.
If the optional transform is specified, the transform origin is translated
by that amount (using the current transformation matrix) for the duration
of the rotate operation.



>
>
> Rik
>
> On Fri, Feb 17, 2012 at 10:06 AM, Dirk Schulze <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'?
>>
>> Dirk
>>
>> 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>
>> 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
>> >
>> >
>> >
>> >
>>
>>
>
>