- From: Alan Gresley <alan@css-class.com>
- Date: Wed, 16 Jul 2014 22:20:56 +1000
- To: Shane Stephens <shans@google.com>, Dirk Schulze <dschulze@adobe.com>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Alan Stearns <stearns@adobe.com>, Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
On 16/07/2014 7:32 PM, Shane Stephens wrote: >> >>> Yes, order matters when you need the transforms to interact. When you >>> don't (when they're all "local"), there's one specific order that does >>> what you want. >> >> “local” seems to be confusing here. All transformations are local for an >> element and take affect on rendering into the parents graphics context. > > > Yeah, local is confusing - all transforms act locally. I think what Tab > means is that there's one specific order for which transforms appear to act > globally as well. Why is local confusing. Can you please read section 6 [1] of CSS transforms. This is what you will read: | Specifying a value other than none for the | transform property establishes a new local | coordinate system at the element that it is | applied to. The is similar to where a value other than visible for 'overflow' establishes a block formatting context [2]. Section 6 also has as follows: | The mapping from where the element would have | rendered into that local coordinate system is | given by the element’s transformation matrix. The 'transformation matrix' is computed from the values of the transform and transform-origin properties. Furthermore, section 6 has a follows: | That is, elements establish their local coordinate | system within the coordinate system of their parent. So each value other than none for the transform property establishes a new local coordinate system. The order in which transforms appear does not effect the transformation matrix but it does effect where the said element *appears* to be positioned globally. Please take note of the last part of example 4. | Note that an identical rendering can be obtained | by nesting elements with the equivalent transforms: | <div style="transform: translate(80px, 80px)"> | <div style="transform: scale(1.5, 1.5)"> | <div style="transform: rotate(45deg)"></div> | </div> | </div> > Say I have an element {top: 0px, left: 0px}, which I want > to: > * move by 500px in x and 200px in y > * rotate by 25 degrees; and > * scale by 1.2 in x and 1.1 in y > > Regardless of the order in which I apply these operations, the element is > always *locally* moved, rotated and scaled - that is, according to the > element's local coordinate system (which changes with respect to the global > coordinate system) the operations are a translate(500px, 200px), a > rotate(25deg), and a scale(1.2, 1.1) regardless of the order in which > they're applied. What if each transform function is done by a chain of nested children? | That is, elements establish their local coordinate | system within the coordinate system of their parent. > Of course, globally, it's a different story. Mostly the element is > *not* translated > globally by 500px, 200px, is *not* rotated by 25 degrees, or is *not* scaled > in x and y by 1.2 and 1.1 respectively. For example: > rotate(25deg) scale(1.2, 1.1) translate(500px, 200px) > Globally, this is rotated by about 27 degrees. It's also significantly > skewed, and it's translated in both x and y by about 450px. No it is not. It is translated in x by 500px and is translated in y by 200px. It is *not* skewed. Each corner is 90deg. Why are you concerned about it's global position? > However, there is one ordering for which the local transformations produce > matching global transformations: > translate(500px, 200px) scale(1.2, 1.1) rotate(25deg) > Globally, this is at position (500px, 200px) (well almost. Technically the > origin has moved by this much). It's scaled by 1.2 in x and 1.1 in y, and > it's rotated against the global x and y coordinate system by 25 degrees. Does the same apply if I have transform-origin: 0% 0% or transform-origin: 100% 100%? Does the same apply if the parent has rotateY(60deg)? > This ordering is clearly special, and clearly has strong advantages for the > purposes of individual rotate, translate and scale properties - the result > of setting these properties will always match across a global and a local > coordinate system. Essentially, we want people to be able to specify: > > { > translation: 500px 200px; > rotation: 25deg; > scale: 1.2 1.1; > } > > and have it Just Work. And this is the only time that it appears like it has be skewed. Again why are you concerned about it's global position? If I did a few transforms for a few ancestors with their own local coordinate system, in theory, you may not have anything to measure against some global position since the said element may be outside the veiwport. >> I think what you meant to say is (correct me if I am wrong) that authors >> most likely just will use one of the transform properties: Either rotate, >> or translate, or scale or transform. And therefore you just want to have a >> sane fallback if an author uses them in combination. >> > > That isn't what we are trying to say. We want beginner authors to be able > to naively specify translations, rotations and scales as if they were > global, and to have them do what they almost certainly wanted them to; but > we want more advanced authors to be able to use the transform property and > control the ordering of transform components as well. There is no global position. It's only due to nativity that one assumes that something has a global position. In my early days of using transforms, I rotated something before translating it. In my early days of using transforms, I didn't realise that the order was important. So what should happen if I have the below styles in this order? Do I have it translating first or do I have it rotating first? { rotation: 45deg; translation: 100px 100px; } > A handy bonus is that having separate translation: rotation: and scale: > properties means it's easy to animate these channels independently of each > other, without resorting to additive animation. > > Cheers, > -Shane You can already do that in some respects. The below code works as expected. @keyframes pframe1 { from { transform: translateZ(-4000px) translateX(-1000px) translateY(1400px) ; } 20% { transform: translateZ(-400px); } 30% { transform: rotateY(-0deg); } 40% { transform: rotateY(-60deg); } 55% { transform: translateY(1400px) rotateY(-180deg); } to { transform: translateZ(500px) translateX(-1000px) translateY(1400px) rotateY(-180deg); } } 1. http://dev.w3.org/csswg/css-transforms/#transform-rendering 2. http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#block-formatting Alan
Received on Wednesday, 16 July 2014 12:21:26 UTC