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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Jul 2014 09:00:02 -0700
Message-ID: <CAAWBYDDspOEoiMw1SuEU=guPrnjz3N69cfomy6tdGVVfnx_+BQ@mail.gmail.com>
To: Alan Stearns <stearns@adobe.com>
Cc: Dean Jackson <dino@apple.com>, Shane Stephens <shans@google.com>, Dirk Schulze <dschulze@adobe.com>, www-style list <www-style@w3.org>
On Wed, Jul 16, 2014 at 6:29 AM, Alan Stearns <stearns@adobe.com> wrote:
> On 7/15/14, 11:22 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>On Tue, Jul 15, 2014 at 10:41 PM, Alan Stearns <stearns@adobe.com> wrote:
>>> Then when Dean brought up the notion of using both transform and rotate
>>> together, your reply assumes that transform does not reset rotate, so
>>> transform is no longer a shorthand and loses the resetting behavior.
>>> second proposal sounds to me like two separate syntaxes for
>>> transformations, one applied after the other.
>>My direct response to Dean was about a transform followed by a
>>translate.  Regardless of what variant of the proposal we use, the
>>answer is the same - the translate doens't do anything to the
>>The rotate preceding the transform does depend on which variant we
>>use. In the original one, 'transform' is a shorthand, so it'll reset
>>the 'rotate' property.  Based on feedback from Dirk and Dean, though,
>>I'm exploring another proposal, where transform isn't a shorthand.  In
>>that, the rotate remains.
>>I don't think "two separate syntaxes" is a very accurate way of
>>thinking about it.  There are just four transforming properties; three
>>of which do single, simple transforms, and the fourth which takes a
>><transform-list> for more complicated things.
> Whether you think of them as two syntaxes or not, there are four
> transforming properties broken into two sets. The first set is the three
> single operations, and they interact with each other (they have a fixed
> order of application).

Here's where everyone keeps messing up, I think due to their
pre-existing hard-won transforms knowledge (and possibly due to my
original framing of the issue).  Using Shane's verbiage, the schm*
properties are just thematically related but otherwise separate
properties.  We'd probably group them together in a spec due to the
thematic relation, but they don't actually interact with each other.
One moves an element around, one rotates an element around its origin,
and one grows/shrinks the elements width/height.  Totally separate
operations that don't interact in any way.  *As usual*, the
'transform' property applies after the schm* properties; nothing new
here, because 'transform' is always a "final" visual effect.

Now, *as it happens*, these three can be implemented by turning them
into transform functions in a particular order and prepending them to
the 'transform' property's value.  That's a technical detail that
honestly doesn't matter to anyone but implementors.  If we never said
anything about this implementations would produce the same behavior,
possibly with more complicated code, but that's it.

> The second set is our current transform property.
> The two sets also interact, as you have to specify the order in which the
> sets apply.
> I expect author guidance will be to use one set or the other, avoiding
> combinations of the two sets (as any combination can be more directly
> expressed by just using the current transform property).

I doubt it, actually.  Nobody advises against mixing relpos and
transforms, even though you can express the former in terms of the
latter, and schmanslation is basically relpos limited to 'left' and
'top'.  There's no direct analogue for schmotation and schmale, but
still, they're like any other effect in CSS, and quite independent of
whatever you do in 'transform'.

Received on Wednesday, 16 July 2014 16:00:49 UTC

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