W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-transforms] Making 'transform' match author expectations better with specialized 'rotate'/etc shorthands

From: Alan Gresley <alan@css-class.com>
Date: Mon, 14 Jul 2014 19:10:52 +1000
Message-ID: <53C39E9C.8040204@css-class.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC