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

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.

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.

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
> >
> >
> >
> >
>
>