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

On Sun, Jul 13, 2014 at 7:04 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Jul 13, 2014, at 5:13 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> transform: <perspective> <translateX> <translateY> <translateZ>
>> <rotateX> <rotateY> <rotateZ> <rotate3d> <scaleX> <scaleY> <skaleZ>
>> <skewX> <skewY> <skew> <transform-list>;
>
> Not be able to change the order transformations apply is a huge limitation of the proposal.

Correct.  This proposal does not solve everything.  It does, however,
help quite a bit.

> Very often translate and rotate need to change places in the multiplication hierarchy.

The current order (translate, then rotate), however, correctly handles
the use-case of "use translate to place the element, use rotate to
rotate it".  There are definitely use-cases for a rotate-first
ordering, but I think the translate-first ordering is probably
extremely common.  (Skew only cares that it's before scale, luckily,
and scale isn't affected by anything else.)

> With a fixed order you are often forced to use ’transform’ anyway. This gets especially clear when you take your ’scale’ example.

Which one?  Three of my examples use 'scale', and I don't see how any
of them have a problematic fixed order.

> While I understand that we need independent levels of transformations (to avoid the use of pseudo elements), I am much more supportive to add ‘auto’ and grouping to the transform property than adding more complexity to the platform. (The complexity comes when we speak about the details.)

Last time I tried to talk about that, literally nobody but me and
Shane were interested.  I'm quite willing to talk about handling
list-valued functions better with a generic mechanism!

That said, even if we did that, I've come to realize that this
proposal is still valuable for usability reasons.

> Furthermore, it is a huge burden to support multiple shorthand “inheritances” (transform <- translate <- translateX)

I haven't heard that before; we have a number of 3-level shorthands
(such as 'border') and more coming (for example, the introduction of
background-position-x/y) and no one's ever objected on these grounds
before.  I'll check with our implementors on this; anyone else from
other browsers should feel free to chime in on this, too.

> and adding 21 *NEW* CSS properties to implementations. This burden affects performance, memory consumption and therefore everyone.

Adding net 13 new properties that actually hold values (14 new core
properties, but we lose transform as it becomes a shorthand).  The
additional properties are just handled during parsing; an
insignificant cost.

While obviously new properties add to the browser's performance
burden, this downside must always be weighed against the benefits.
This group has never accepted "CSS has enough properties already" as a
valid argument.

> If we must have new properties to handle author mistakes (not speaking about the current limitations from above that we need to fix anyway) then:
>
> 1) Have a default order for applying transformations. Do not introduce short-/ or longhands.

Not having a way to reset all of the transforming properties is bad.
We need to maintain the part where 'transform' is a shorthand for
'transform-list' and resets everything else.

> 2) Add a property to influence the order of the transformation
>
>         transformation-order: rotate || translate || scale || transform
>
> 3) Just expose the most common used transformations as properties:
>
>         scale: <number>{1,3}
>         translate: <length>{1,3}
>         rotate: <angle>
>         transform: <transform-list>

This is possible, if we think it's all that's necessary.  I'm happy to
argue the relative merits of using just the most-common properties
versus being exhaustive.  For example, if we wanted to keep the larger
list, maybe we could have only one 'rotate' property.

> However, this does not explain how to apply an individual transform-origin for each of the transformation properties. Scale and rotate depend on influencing the transform-origin. This is especially true if you can not use translate(offset, offset) scale(factor) translate(-offset, -offset).

I thought they'd just all use the same origin.  If we think it's
important, we can augment the grammar of each to allow an optional
origin() function, which provides the origin for that transform.

> I can just repeat that author mistakes like rotate: 45deg; can easily be detected by authors themselves and therefore don’t require us adding more complexity to the platform.

I'll repeat again that it's not really about mistakes; CSS generally
doesn't error-correct beyond recovering at the next available point.
It's the fact that common errors often point to badly-designed APIs;
they indicate a clash between the model as written and the model as
people understand it.  This is a *very* common mistake (I do it
regularly, and according to the Twitter responses, so do plenty of
other people), making it fairly likely that we have a significant
mental-model mismatch here.

~TJ

Received on Sunday, 13 July 2014 22:47:03 UTC