Re: [css3-2d-transforms] "longhand" for the transform stack

On 25/03/2011, at 9:14 AM, Aaron Gustafson wrote:

> On Thu, Mar 24, 2011 at 4:22 PM, L. David Baron <dbaron@dbaron.org> wrote:
> 
> The issue here is that the values of 'transform' are an *ordered*
> list of transformations.  For example, the following two transforms
> are different:
>  translateX(100px) rotate(45deg)
>  rotate(45deg) translateX(100px)
> 
> So if we wanted longhand transform properties, we'd need to give the
> one true order for the operations, and say how those operations
> interacted with the ones in the 'transform' list (which *can't* be
> decomposed into subproperties since it's an ordered list, and
> decomposing it would lose that order).
> 
> 
> That certainly makes sense and is something I hadn't considered, but I do still think we should look for some balance. On one hand there's the incredible power inherent in specifically ordering your transformations and on the other hand there's a desire to easily (and with limited repetition) being able to successfully manage ever more complex stacks of transformations.
> 
> I'm just spitballing, but here are a few thoughts:
> 
> 1) Probably the simplest option: an "ordered" prefix/suffix - transform-ordered (or ordered-transform) for instances when you want to control the full stack in a specific, ordered way; transform itself would follow a prescribed order that would also affect longhand versions of the properties.

I think it's too late to change what 'transform' means. Note that this has existed in SVG for more than 10 years now.

> 
> 2) Adding a priority to each transformation. This probably requires an example:
> 
> #foo {
>   transform: translateX(100px, 1) rotate(45deg, 2);
>   /* translateX applied first, then rotate) */
> }
> #bar {
>   transform: rotate(45deg, 2) translateX(100px, 1)
>   /* translateX still applied first, then rotate) */
> }
> #foo.state-2 {
>   transform-rotate: 45deg, 1;
>   /* rotation now given higher priority in transformation stack */
> }
> 
> Of course, under this rubrick, my guess is that you'd want the cascade to resolve conflicts in priority (where 2 transformation methods have the same priority).
> 
> Thoughts?

Yeah, that this is more complicated than the current behaviour :)

I don't think the current transform is too confusing, and allows you to do things like this.

transform: translate rotate translate scale translate rotate;

ie. apply multiple instances of functions to the same element. 

It seems the main inconvenience from your original post is that you have to duplicate the entire list of transformation functions each time. Is that really a big deal?

Dean