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

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:

* 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 Friday, 11 July 2014 18:43:26 UTC