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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 6 Aug 2014 09:55:02 -0700
Message-ID: <CAGN7qDCW6pj-PpJi+EAUzgJFOCPnwq0pqmmRrxkBFWxtqtWUtA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Wed, Aug 6, 2014 at 9:43 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Aug 6, 2014 at 11:38 AM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Thursday 2014-07-17 09:47 -0700, Tab Atkins Jr. wrote:
> >> I propose we add the following three properties to the Transforms spec:
> >>
> >> * translate: <length>{1,3}
> >>     - specifies a translation in the X, Y, and Z axises, respectively.
> >> Missing values default to 0.
> >> * rotate: <angle> <number>{3}? <'transform-origin'>?
> >>     - specifies a rotation along a given axis from a given origin. An
> >> omitted axis defaults to 0,0,1; an omitted origin defaults to
> >> 'transform-origin's initial value.
> >> * scale: <number>{1,3} <'transform-origin'>?
> >>     - specifies a scale in the X, Y, and Z axises, respectively, from
> >> a given origin. Missing values default to 1; an omitted origin default
> >> to 'transform-origin's initial value.
> >
> > I'm mostly ok with this.  One concern is about the syntax of the
> > <'transform-origin'>? bits at the end of the 'scale' and 'rotate'
> > properties; I wonder how readable they are as written.  I think an
> > author seeing a declaration looking like:
> >
> >   scale: 0.5 0.3 50px 25px;
> >
> > might find such a declaration confusing.  I wonder if the
> > transform-origin would be better separated somehow, e.g., with a
> > function:
> >
> >   scale: 0.5 0.3 origin(50px 25px);
> >
> > (I also wonder whether there's any risk of future syntax collisions
> > between the two.  There's certainly a risk of having to take a bit
> > of work to figure out which value something belongs to, e.g., with
> > calc().)
>
> Good point.  I'm fine with either adding a separator (using /?) or a
> wrapping the origin in a function to name it.
>
> And you're right about collisions - if we ever allow SVG userspace
> units, they'll collide with the 'scale' numbers
>

I think it's very rare for transformations to specify different origins. I
don't know of any tools that allow this.

If we do keep it, the origin of rotate and scale should have the previous
transformations applied to it (ie origin of rotate = origin * translate,
origin of scale = origin * translate * rotate).
This is likely not the initial value.
Received on Wednesday, 6 August 2014 16:55:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 6 August 2014 16:55:31 UTC