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

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 06:23:12 UTC