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

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.

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

> 
> 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?

Example:

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

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 05:53:33 UTC