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

On Jul 11, 2014, at 8:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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

Ok.


> 
> 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 Saturday, 12 July 2014 06:23:40 UTC