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

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.

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 :)
>


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.


I don't think the current transform is too confusing,
>


I can't say I'm surprised... you work at Apple. You're no doubt quite close
to the implementation as it is right now, so of course it makes sense to
you.

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.



> 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.
>


That's great stuff, really it is. But how many web designers out there want
or need to stack multiple instances of the same function on a given element
at this point in time? 1%? 2%? As it stands, the syntax is incredibly
powerful, but not very practical.



> 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).

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.

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). 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.

I'm sure there's more I'm forgetting, but these are the ones at the top of
my list.

Cheers,

Aaron

----
Aaron Gustafson
Principal
Easy! Designs, LLC
+1 877 EASY 313 x101
aaron@easy-designs.net
@aarongustafson