- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 6 Aug 2014 10:13:13 -0500
- To: www-style list <www-style@w3.org>
"Quick" pre-call summary of this message: * The 'transform' function introduced, among all its new abilities, three things that authors commonly use: translating, scaling, and rotating elements. * Authors often use TRS effects "independently"; that is, they might want to rotate an element when some selector applies, while also translating it in an animation. * TRS are only usable by writing them together in a transform list. This has several downsides: - There is only one ordering of the three functions that make the three effects work "independently"; that is, working so that each function has approximately the same effect whether specified alone or with the other functions. That order is TRS, and any of the other six orders ties the effects together in non-obvious and intrusive ways. (Rotate before translate makes your "positioning" move along a rotated axis, putting the element in an unexpected place. Scale before rotate causes your element to squish in unpredictable ways, rather than just getting bigger or smaller and also rotating.) - CSS still has no way of tweaking individual parts of a list-valued property independently, so it's difficult to combine effects together that rely on different selectors (you have to repeat the unrelated effect in the other selector, and combining animations is impossible). - Even if we eventually add "additive" animations and similar things, that wont' help 'transform'. (Additive combinations require either an explicit ordering, or commutativity, and we have neither when combining together multiple 'transform' values.) * Because authors often think of TRS effects as independent things (in other words, "I want to rotate this element on hover, and I want to scale it on click", not "I want to apply this rotate/scale transform on hover, this rotate/scale transform on click, and this rotate/scale transform on hover+click"), it's very common to accidentally start typing out the desired transform function as the property name. We can make this intuitive usage correct, and improve how closely we hew to common mental models. * The Transforms spec already has two "independent" properties that can be 100% emulated by just adding more transforms to the transform-list. 'perspective' and 'transform-origin' are technically superfluous (the former can be replaced by a perspective() at the front of the transform-list, the latter by a pre and post translate(), though I'm not sure what the correct relative ordering of perspective() and translate() is at the start of the list). We have them, though, because they have "independent" effects that can be described without having to think about them as having a complex interplay with the other transforms in the list, and because it's useful to have them cascade separately and be tweakable separate from the transform-list. For all these reasons, I propose adding 'translate', 'scale', and 'rotate' functions to the Transforms spec, with the grammars and effects stated in the previous message. As a bonus proposal, I propose making them shorthands, breaking 'translate' apart into -x, -y, and -z, breaking 'rotate' apart into -angle, -axis, and -origin, and breaking 'scale' apart into -x, -y, -z, and -origin. I think this is a great idea (note, for example, how background-position tying together x and y was so annoying to authors that two different browsers added the same proprietary -x and -y extensions), but it's not strictly required; don't let opposition to this get in the way of accepting the 3-property main proposal. ~TJ
Received on Wednesday, 6 August 2014 15:14:01 UTC