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

On 29/03/2011, at 8:49 AM, Aaron Gustafson wrote:

> 
> 
> On Fri, Mar 25, 2011 at 8:17 PM, Dean Jackson <dino@apple.com> wrote:
> 
> I think it's too late to change what 'transform' means. Note that this has existed in SVG for more than 10 years now.
> 
> 
> I understand where you're coming from, but I'm approaching this from an author's standpoint, not from that of an implementor or a spec writer. If more web designers wrote SVG by hand (and had been doing so for the last 5-10 years), it might not be a problem, but the fact is that, by and large, they haven't. And speaking as someone who is frequently called on to train folks on these new techniques and technologies, the truth is that the current transform setup isn't easy to grasp.

Understood. My point was that we can't make a change now that would break existing content in SVG or CSS.

> 
> Of course it is. As I said, I'm spitballing here. I think this is a discussion we need to have and there are likely to be a number of harebrained ideas that come out of the discussion, but if we have this discussion we can (hopefully) get to a place where the spec meets the needs of authors as well as implementors. 

A thought I had after I replied was that it *might* be possible to make transform take a list of lists, sort of like background-image.

eg:

transform: scale(2), rotate(10deg);

which would mean apply a scale then a rotate. Then have a magic keyword that means to use whatever the current value for the functions in that spot are.

transform: same, rotate(20deg);

That would keep the scale the same but add another 10 degrees of rotation.

The problem is that it means there is a difference between space separation and comma separation. Is this easy to work out?

transform: scale(2) rotate(10deg), rotate(-10deg) translate(10px, 3px) scale(3), translate(-40px, -20px);

Probably yes, because it would actually be the same as without commas (other than the necessary ones within functions). Now suppose we move to this:

transform: same, rotate(50deg), same;

I still think the added complexity isn't worth it. I've not seen many complaints over confusion of ordering from authors. The most common request is exactly what you're asking for, a way to modify just a particular parameter, but they usually understand the issue with ordering.

>  I'm not debating the power and flexibility of the current transform proposal, but I am trying to figure out if there's a better/alternate way to provide access to the power of transform that is easier for authors to wrap their heads around and that serves their actual needs (rather than hypothetical ones). I find the current implementation lacking in that area.

I'd be interested to hear the use case? As Simon pointed out in another reply, the way most authors address this issue is by nesting elements.

<div style="transform: scale(2)">
  <div style="transform: rotate(10deg)">
    <img src="whatever.png">
  </div>
</div>

That way you can tweak rotation and scale independently quite easily. In fact you generally need to do this if you want to animate each at different rates.

>  
> 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?
> 
> 
> Yes, actually. Here are the problems/reasons for my post to begin with any why I think the current syntax and implementations are not author-friendly:
> 
> 1) It's not intuitive - many designers and developers have a hard time grasping that there is only the transform stack and that whenever you set a value for it with a more specific selector, all previously-applied transforms are dropped and there's no way around it. Having an alternate syntax for "simple" transforms could address that (e.g. setting rotation on an element would not need to interfere with scale set elsewhere).

I understand this, but the problem is that transforms don't really work this way. As an author, you need to decide the order of transform functions. If the specification decided one way, then there would be a bunch of people who wanted it another way.

It might be possible to add three new properties that are applied before the regular transform property. 'transform-scale' '-rotate' '-translate'. This would probably address your need in the simplest manner, and would be easy to implement. We'd define the order.

> 2) It leads to source bloat - this setup does not help us keep with the DRY principle (don't repeat yourself), which leads to larger files and longer downloads. Having an alternate syntax would help us keep our files smaller.

It's true that source files are bigger, but since you're using a very similar pattern in each instance I doubt it makes a big difference in (gzipped) download.

> 3) Tweaking an element's style.transform property via JavaScript is unnecessarily complex (as the current state is pretty much always exposed as a matrix and it is difficult to suss out the current state in order to make adjustments).

Yeah, that's ugly. Your only option on the reading end is to look at the property value and parse it yourself :( Reading is definitely hard, but writing is a little easier. There is an API to, say, scale a matrix by 3. That only helps if you are adding to what is there.

> Being able to _easily_ determine properties such as the current rotation angle would be a godsend.
> 
> 4) JavaScript-based class-swapping produces the smoothest transition effects, but (again) requires a lot of extra CSS code for anything more complex than a stack of one or two transforms. If we had longhand properties, we'd be able to streamline the classes used for JavaScript-triggered animations.

What do you think about adding the extra properties above?

Dean