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

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.

~TJ

Received on Wednesday, 6 August 2014 16:43:49 UTC