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

Ugh, I am the WORST. Reposting this with correct tag and subject line.
This thread is now dead, don't post to it.

On Fri, Jul 11, 2014 at 11:34 AM, 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:
>
> * 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:42:33 UTC