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

On Mon, Mar 28, 2011 at 6:43 PM, Dean Jackson <dino@apple.com> wrote:

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


SVG I understand. On the CSS front, it's not a final spec yet, so I'm not
really all that concerned about "breaking existing content" because all
current implementations should be using vendor prefixes, meaning they're
experimental and subject to change. That's the whole point, right?


> 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 think it's an interesting idea, but it seems like it could get really
confusing really quickly.

In terms of complaints from authors, I'm starting to see them as more people
have begun to dabble. People familiar with SVG and transformation matrices
(e,g, animators and the like) probably won't have any problems picking this
up. Your average web designer or developer, however, is likely to be
overwhelmed. I think there's a balance to be struck between a the power of a
technology and an author's ability to easily comprehend that technology. If
we don't find that balance, adoption may be considerably slower than many of
us would like.


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


I guess it depends on the level of purist you want to be. Sure, you could
add the extra markup to accomplish this, but should you have to? More on
this below.


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


Agreed. Modified consensus would be the only way to progress on the spec,
and that's probably too much to hope for.



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


I think having "longhand" versions of the properties would make a lot of
sense, but (like Kenny), I'd probably argue for applying them *after* the
translate stack. Again, more in a second.


> 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.
>
>
Possibly. But maintainability is also an issue with so much potential
repetition.


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


Where can we have a discussion about address that? We need a better API
capable of giving us information back about the current state of things
(like current rotation, scale, etc.).


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


Ok, so I think the extra properties are great (but I think there'd be more
than three... you'd want one for each transform function). I think the
question becomes: should they be applied before or after? Before allows you
to keep the primary transform stack as the primary mechanism for element
manipulation. After allows you to make singular augmentations to an existing
stack. Which is more likely to be useful? I'm not sure I know the answer to
that.

One thing I do know, and this goes to your earlier comment about timing the
transition of two transform function separately, by allowing us to separate
transforms out from the stack, it would enable us to animate each transform
function independently without requiring additional markup:

img:hover {
  transition: transform-scale 3s, transform-rotate 5s;
}

Of course the question then becomes: Would setting the transition timing for
a "longhand" transform property affect the transition of that function in a
transform stack? I'm guessing the answer to that is probably "no," but I
thought I'd ask.


On Mon, Mar 28, 2011 at 7:53 PM, Kang-Hao (Kenny) Lu <kennyluck@w3.org>
 wrote:


> In light of this, what about a new property called "also-transform",
> which cascades separately and happens after "transform"? This idea can
> be extended to "also-background" and is sort of a solution to ISSUE-177,
> but as this looks ugly, I wouldn't say I really like this solution.
>
> I think this might be a use case that the CSS Mixin module (if we create
> it) might want to address. A less uglier might look like "+transfrom:
> rotate(40deg)".
>


It's an interesting idea, for sure.

Cheers,

Aaron

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