- 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