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 23:19:30 -0700
Message-ID: <CAGN7qDCKP47857yfexo1dnux68ev=ZqsJhJSAzheusXxQuopPA@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Wed, Aug 6, 2014 at 10:53 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Aug 6, 2014, at 6:55 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> >
> >
> >
> > 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;
>
> We have this syntax for rotate already. It is used very often in the case
> of SVG.
>
> > >
> > > 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.
>
> Illustrator and Photoshop, both let you change the origin for the next
> transformation. But then again, we collapse them to one matrix at the end
> as you can see in the SVG output from Illustrator. IIRC Inkscape does the
> same.
>

Exactly, AI and PS don't remember the transform-origin; they are not
designed as animation tools.
They just apply the transform and the user can optionally change the origin
at any point (which is very uncommon)


> It is extremely common for rotate in SVG! Especially because we did not
> have transform-origin in SVG 1.1.


Of course, but CSS has transform-origin so that point is moot.
I'm not advocating to remove it from the longhand.


> >
> > 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.
>
> I think the origin bits are the interesting part for rotate and scale. As
> I understand Shane, he wants everything to be expressed in the
> untransformed coordinate space. So would be the expression of the origin.
> That means that we have to multiply the origin of scale (and for rotate as
> well) with the inverse of all previous transformations for the current
> element. Is it that what you mean Rik?
>

I'm unsure, but it sounds like Shane's suggestion should not apply to the
origin as it should transform in space.


> Example:
>
> translate: 20px 20px;
> rotate: 45deg 40px 40px;
>

For this case, the transform origin in untranslated space should be 60 px
60px


> When applying rotate, you would need to do translate(20px 20px) *
> inverse(translate: 20px 20px) * translate(40px 40px) * rotation *
> inverse(translate: 20px 20px) * translate(-40px -40px) to get the
> translation. (I might miss something though.)
>
> translate: 20px 20px;
> rotate: 45deg 40px 40px;
> scale: 2 4 50px 50px;
>
> For the origin of scale it would be the inverse of all previous
> transformations.
>
> Greetings,
> Dirk
>
>
>
>
>
>
>
Received on Thursday, 7 August 2014 06:20:02 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 7 August 2014 06:20:06 UTC