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

On Fri, Jul 11, 2014 at 11:22 PM, 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?

No, I think we should expose all of them.

> 2) If you define more than one different transform function, do you post multiply or pre multiply?

What do you mean?  I defined the ordering of properties in my
proposal; is something missing?

> 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).

...yes?  That's how CSS works.

> 4) Making longhands makes it harder to workout grouping of transform functions (for animation purposes) later

How? Note that my proposal preserves the current functionality of
transform, in the transform-list longhand.  Whatever we do for
animation grouping in the future will apply to *that*.

> 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?

I defined that in my proposal.  You seem to be assuming that
"transform: rotate(45deg) translate(20px, 20px)" will expand into a
"rotate" and "translate" property; read my proposal again, please.

> 6) Shorthands already require special attention from UAs. As less shorthands as better.

Depends on the shorthand; simple ones are basically a one-liner.  This
is an extremely simple one, since all it does is copy the 'transform'
value into 'transform-list' and reset all the rest.  The other handful
of transform-function shorthands are similarly trivial, because the
transform function grammars don't have any reordering or complexity:
'translate3d', for example, would just copy its first value to
'translateX', its second to 'translateY', and its third to
'translateZ'.

I have never heard an argument that shorthands are a complexity
problem that should be avoided.  I'm not willing to accept it as an
argument against without more support from other implementors.

> 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.

Based on your responses, it appears you only skimmed my proposal, and
don't actually understand the details of it.  I'd appreciate a
reassessment after studying it a bit more.

> 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.

Validating the author's mistake was only one of the reasons behind my
proposal (the other was allowing some basic "separation" of
transforms, so you could, say, animate something's position with
'translate', while rotating it on hover).  That said, don't write it
off.  Common authoring mistakes are a sign that *we* made a mistake;
it means that something does not match a common internal model.
Sometimes that's fine, and authors just need to learn how it works;
other times it means we should tweak things to move closer to the
author's internal model.

If you read the tail end of that Twitter thread, you see a bunch of
authors sounding off enthusiastically about this.  This is *very*
common, and would make a lot of authors very happy, I think.

~TJ

Received on Saturday, 12 July 2014 15:48:28 UTC