W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: [css3-transforms] transform-origin vs translate was(transform-origin syntax: 3D vs. background-position)

From: Alan Gresley <alan@css-class.com>
Date: Fri, 02 Mar 2012 15:55:55 +1100
Message-ID: <4F5052DB.1030303@css-class.com>
To: Aryeh Gregor <ayg@aryeh.name>
CC: public-fx@w3.org
Changing subject line since I do intend on returning to that topic

On 2/03/2012 5:54 AM, Aryeh Gregor wrote:
> On Mon, Feb 27, 2012 at 9:57 PM, Alan Gresley<alan@css-class.com>  wrote:
>> What I mean is that 'transform-origin' is relative to the transformed
>> element with rotate* and skew* and not it's parent. This is seen in the
>> below test case.
>> http://css-class.com/test/css/3/transforms/transform-origin1.htm
>> Also the transformed element only has two dimensions (it does not have
>> width:<value>, height:<value>  and depth:<value>  for three dimensions).
> All of that is true.  I don't understand how it's relevant to your
> question, though.

If you believe that transform-origin with a z value is the same as 
translateZ, I can understand why you may believe it to be not relevant.

>> I not sure exactly what you mean by 10px off this screen. Is this the z-axis
>> of the transformed element or the z-axis of the transformed element's
>> parent?
> transform-origin is always specified relative to the top left corner
> of the current element's border box, before any transformations are
> considered.

Correct in respect to the x-axis and y-axis.

>> If this is different from the default, then I am presuming the later, thus
>> it does not behave in the manner as if I had used translateZ(10px).
> It does behave exactly the same.

True, but only since translateZ(10px) is translated in respect to the 
parent. This is somewhat like positioning and offset.

>> I do not understand what 'before the transform list' or 'after it' means and
>> I do not know the difference between (-X, -Y, -Z) and (X, Y, Z) but one day
>> I would like to know (I just have good spatial
>> awareness). Is it indicating two reference frames [1].
> All I'm saying is that, for instance,
>    transform: rotateX(75deg) scale3d(1.2, 0.6, 7);
>    transform-origin: 25% 75% -20px;
> is exactly the same as
>    transform: translate3d(-25%, -75%, 20px) rotateX(75deg) scale3d(1.2,
> 0.6, 7) translate3d(25%, 75%, -20px);
>    transform-origin: top left;
> and similarly for any usage of transform-origin.  transform-origin
> isn't actually necessary itself -- you can always use translate*()
> instead.  It just makes things easier to think about.

I will agree that the maths is correct (I wouldn't dare to question) but 
you can not confuse translate*() with transform-origin. The two examples 
below *do not* do the same thing with transformed elements.

   transform: translateX(25%) translateY(25%);
   transform-origin: 25% 25%;

The only thing that appears to stay the same is where the point of 
'transform-origin' is in respect to the transformed element (not the 
parent). A test case.


(I should note that the examples on the right shows identical if you had 
transform-origin: 50% 50% since this is the default)

>> What I believe is wanted is a translation from the parent which is indicated
>> by the lime line marker (z axis of parent) in this test case (best to view
>> in Safari).
>> http://css-class.com/test/css/3/transforms/translate-transform-origin2.htm
>> If you hover the test, you will notice a transform that also has
>> rotateZ(90deg) and translateZ(50px). Notice how this keep the intersection
>> of the X and Y axis (the point of transform-origin) relative to the red line
>> marker (z axis of transformed element).
> I don't have access to Safari, and I'm afraid I don't understand your test case.

By what you have said above, you have already clarified my question. 
Anyway, a screenshot.


Note how Safari (far right) shows the red line marker intersecting with 
the x-axis and y-axis of the the transformed element (FF12/Aurora also 
does this correctly) which is also the same point where the transformed 
element plane intersects with the parent's plane (only seen correctly by 
Safari on Windows, not sure on MAC). I presume you are aware of the 
various intersecting plane painting bugs.

I'm wondering why you could not check this with Safari on Windows 8 
preview. I would have no idea how Safari on Mac behaves since I only 
have Windows 7 which means I am clueless to how IE10 handles 3D-transforms.

Alan Gresley
Received on Friday, 2 March 2012 04:56:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:46 UTC