- From: Alan Gresley <alan@css-class.com>
- Date: Fri, 02 Mar 2012 15:55:55 +1100
- 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. http://css-class.com/test/css/3/transforms/translate-transform-origin4.htm (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. http://css-class.com/test/temp/transform-intersect-z-axis.png 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 http://css-3d.org/ http://css-class.com/
Received on Friday, 2 March 2012 04:56:27 UTC