W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: [css-transforms] Adding specialized properties for simple transforms

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 6 Aug 2014 10:13:13 -0500
Message-ID: <CAAWBYDA46z+tAzoCLYCoKipbgKMQZYZJ4QxW8-z63H+-DwA0fw@mail.gmail.com>
To: www-style list <www-style@w3.org>
"Quick" pre-call summary of this message:

* The 'transform' function introduced, among all its new abilities,
three things that authors commonly use: translating, scaling, and
rotating elements.
* Authors often use TRS effects "independently"; that is, they might
want to rotate an element when some selector applies, while also
translating it in an animation.
* TRS are only usable by writing them together in a transform list.
This has several downsides:
    - There is only one ordering of the three functions that make the
three effects work "independently"; that is, working so that each
function has approximately the same effect whether specified alone or
with the other functions.  That order is TRS, and any of the other six
orders ties the effects together in non-obvious and intrusive ways.
(Rotate before translate makes your "positioning" move along a rotated
axis, putting the element in an unexpected place.  Scale before rotate
causes your element to squish in unpredictable ways, rather than just
getting bigger or smaller and also rotating.)
    - CSS still has no way of tweaking individual parts of a
list-valued property independently, so it's difficult to combine
effects together that rely on different selectors (you have to repeat
the unrelated effect in the other selector, and combining animations
is impossible).
    - Even if we eventually add "additive" animations and similar
things, that wont' help 'transform'.  (Additive combinations require
either an explicit ordering, or commutativity, and we have neither
when combining together multiple 'transform' values.)
* Because authors often think of TRS effects as independent things (in
other words, "I want to rotate this element on hover, and I want to
scale it on click", not "I want to apply this rotate/scale transform
on hover, this rotate/scale transform on click, and this rotate/scale
transform on hover+click"), it's very common to accidentally start
typing out the desired transform function as the property name.  We
can make this intuitive usage correct, and improve how closely we hew
to common mental models.
* The Transforms spec already has two "independent" properties that
can be 100% emulated by just adding more transforms to the
transform-list.  'perspective' and 'transform-origin' are technically
superfluous (the former can be replaced by a perspective() at the
front of the transform-list, the latter by a pre and post translate(),
though I'm not sure what the correct relative ordering of
perspective() and translate() is at the start of the list).  We have
them, though, because they have "independent" effects that can be
described without having to think about them as having a complex
interplay with the other transforms in the list, and because it's
useful to have them cascade separately and be tweakable separate from
the transform-list.

For all these reasons, I propose adding 'translate', 'scale', and
'rotate' functions to the Transforms spec, with the grammars and
effects stated in the previous message.

As a bonus proposal, I propose making them shorthands, breaking
'translate' apart into -x, -y, and -z, breaking 'rotate' apart into
-angle, -axis, and -origin, and breaking 'scale' apart into -x, -y,
-z, and -origin.  I think this is a great idea (note, for example, how
background-position tying together x and y was so annoying to authors
that two different browsers added the same proprietary -x and -y
extensions), but it's not strictly required; don't let opposition to
this get in the way of accepting the 3-property main proposal.

Received on Wednesday, 6 August 2014 15:14:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:24 UTC