- From: Alan Gresley <alan@css-class.com>
- Date: Mon, 14 Jul 2014 19:10:52 +1000
- To: fantasai <fantasai.lists@inkedblade.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On 14/07/2014 5:23 PM, fantasai wrote: > On 07/11/2014 11:42 AM, Tab Atkins Jr. wrote: >> Earlier today I saw a Twitter thread started by Lea >> <https://twitter.com/LeaVerou/status/487350702386479105> about how she >> commonly accidentally types the name of the transform she wants as the >> property (like "rotate: 45deg;") and then has to go back and correct >> it afterwards. Several other devs chimed in that they do this as >> well, and I know that I've done it a few times (especially when using >> SVG - I use "transform='translate(...)'" so often that I commonly try >> to name the attribute "translate" first). >> >> Since this is something that devs trip over so much, it might be worth >> accommodating it in the syntax. I think we can do this compatibly >> with the current syntax. Here's a proposal: > > Having read the thread so far, I think this is a problem worth solving. > However, I agree with most of Dirk's and all of Sylvain's comments, so > I'm in support of a proposal that incorporates their feedback. Agree. > On that note, if there needs to be separate origins for the longhands, > they should not be handled as origin() functions as you propose [1], > since you generally want to cascade the origin and the value independently. Why? I can see reasons why you would want to use a different origin on hover. The below would be exposed to most functions of the transform either being longhand or a transform-list. el:hover { transform-origin: bottom right } > An origin() function might be useful for translate-list, however, to > avoid the awkward translate-untranslate pattern Dirk mentions [2]. How is this awkward? The property 'transform-origin' does not effect translate, translateX, translateY, translate3d and translateZ. Only scale, rotate, skew and matrix depend on transform-origin. What Dirk stressed was translate and rotate in the multiplication hierarchy. Like what is applied first with the below two scenarios. el { transform: rotate(45deg); translate: 100px, 100px; } el { transform: translate(100px, 100px); rotate: 45deg; } transform-origin would or should not work with the latter one if it's contained within transform shorthand as origin(). > [1] http://lists.w3.org/Archives/Public/www-style/2014Jul/0207.html > [2] http://lists.w3.org/Archives/Public/www-style/2014Jul/0202.html > > Regardless, this should almost certainly go into a Transforms Level 2 > draft, since the set of features in Level 1 has already shipped. To > that end, it would be nice to have Transforms in CR sometime soon. :) > > ~fantasai Agree. I am liking the possibilities. Alan
Received on Monday, 14 July 2014 09:11:24 UTC