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

Hi Dirk,

It looks like you didn’t read the entire twitter discussion Tab linked to. Not only did authors unanimously agree that something like this would ease their pains, but they didn’t only cite brevity and ease of use as reasoning, like you seem to assume. Many mentioned that they want to be able to control these transforms independently, animate them separately etc without having them override each other. It’s not just syntactic sugar.

Regarding your questions:
1. If property number is such a concern, we could start with the 2D transforms only, which are only 10. Though I remember chatting with implementors a while back and getting the impression that property number is not such a huge overhead.
2. Tab already answered this. He wrote “The specialized properties apply in some arbitrary predefined order.”.
3. In my experience, newbie authors have zero trouble understanding that same property declarations override each other. In fact, they have much more trouble understanding the opposite: That the same transform functions in <transform-list> don't override each other. Also, nothing in your example changes pre- to post-multiply (see above).
4. How so?
5. See 2 & 3 above. I think you’re misunderstanding Tab’s proposal.

Btw, in addition to the tweets, lemme add that I’ve ran a lot of CSS workshops and students who are new to transforms ALWAYS make this mistake in the transforms section and can’t figure it out as quickly as you might think. The argument “this is a mistake that can be figured out very quickly” can be made for any UI with usability issues, but it doesn’t mean that attempts shouldn’t be made to make it more usable. Even if we assume it’s a mistake that people generally figure out in ~2 minutes, 100,000 authors making that mistake 10 times equals 2 years wasted. And all three of these numbers are very conservative estimates.

Needless to say, I strongly support this proposal. There are many details that need to be figured out about it, but I think it’s worth the effort.

~Lea

On Jul 12, 2014, at 09:22, Dirk Schulze <dschulze@adobe.com> wrote:

> 
> On Jul 11, 2014, at 8:42 PM, Tab Atkins Jr. <jackalmage@gmail.com> 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:
> 
> I commented on the tweet before. But since 140chars are not enough sometimes:
> 
> 1) We have 21 transform functions. Turning all into longhand properties is clearly not a goal here. How do you justify which one of gets exposed to a property and which doesn’t?
> 2) If you define more than one different transform function, do you post multiply or pre multiply?
> 3) If you define more than one property with the same name it gets overridden. This is well known knowledge for CSS experts, not so much for authors new to CSS and confusing. Example: 45deg; translate: 20 20; rotate: 15deg;. Last orate overrides first one and even changes post to pre multiply (or the other way around).
> 4) Making longhands makes it harder to workout grouping of transform functions (for animation purposes) later
> 5) The order of transform functions matter. How do you define that a longhand overrides a certain part of the shorthand? And which would it override? What if you have more than one transform function of the same type in the shorthand?
> 6) Shorthands already require special attention from UAs. As less shorthands as better.
> 7) Did I mention that we have 21 transform functions and that it is unclear how to justify which gets exposed as property?
> 
> While I acknowledge that it can happen that one writes translate: … or rotate: … accidentally, it is a mistake that can be figured out very quickly. Solving this is over engineering IMO. I am opposed to this proposal.
> 
> Greetings,
> Dirk
> 
>> 
>> * Turn 'transform' into a shorthand for the longhand properties
>> 'transform-list' (taking the current syntax), 'rotate', 'translate',
>> 'skew', etc (one for each transform function).  'transform' maintains
>> its current syntax, and is only capable of directly setting
>> 'transform-list' (by copying its value straight over), but it resets
>> the other properties. ('perspective' already exists and is not reset
>> by 'transform', so we'd need to keep it separate, as a legacy
>> exception.  This makes sense anyway, as the reason we have a separate
>> 'perspective' property in the first place is that you often want it to
>> cascade separately from the rest of the transform.)
>> 
>> * The various specialized properties have value grammars equal to
>> their current argument grammars (plus a "none" value), and work in the
>> same way.  Properties are either aliases (if their functions are
>> equivalent, like translate() vs translate3d()) or longhand/shorthands
>> (if some functions set components of a more general function, like
>> translate() vs translateX()).  (Should we maintain the function naming
>> exactly, so you get a property name like 'translateX', or convert to
>> dashes, like 'translate-x'?  I'm leaning toward maintaining the name
>> exactly.)
>> 
>> * The specialized properties apply in some arbitrary predefined order.
>> The matrix interpolation decomposes them in the order
>> translate/rotate/scale/skew, so we'd do the same, I guess.
>> 'transform-list' would apply last.
>> 
>> This proposal not only addresses a common authoring mistake (read as:
>> usability hazard), but it also lets off some of the pressure for
>> better handling of list-valued properties, as it would let authors
>> independently cascade 'rotate' against 'translate', etc.  It doesn't
>> do everything, and we'll need to handle indexed longhands eventually,
>> but at least we can delay longer while addressing one of the most
>> persistent sources of complaints on this front.
>> 
>> Thoughts?
>> 
>> 
>> ~TJ

Received on Saturday, 12 July 2014 17:57:53 UTC