Re: [css3-transforms] Making transform-origin a list, converting transform to comma separated

On 4/2/12 23:40, Dean Jackson wrote:
>
> On 04/02/2012, at 5:13 AM, Lea Verou wrote:
> I don't see any strong reason for consistency here. It's already consistent with SVG as you mention, and I don't think anyone is confused. Filters have a similar syntax. Adding commas would be more typing.

Chances are, most people using CSS transforms have used other CSS 
properties, but they may have never used SVG. Also, it's thanks to CSS 
transforms deviating from SVG that we now have a much more usable system 
(SVG doesn't have transform-origin for example), which SVG is likely to 
adopt.

Filters are a new spec, and I suspect they adopted that kind of syntax 
precisely to be consistent with CSS transforms.

> I think both accepting multiple origins (comma separated list) and an origin() method are prone to confusion.

How so?

> I suspect in most cases it would be more clear to add any origin transformation into the transform function directly (either verbosely with translate(-origin) XXX translate(origin),

Please keep animations in mind. This is where origin is most useful in. 
In static transforms, everything can be emulated by an extra translate() 
anyway.

> or enhance the function syntax so that each function takes more parameters).

I think it's pretty widely accepted that the most (unnamed) parameters a 
function has, the less obvious what it does is.

Also, this is not a per-transform function issue. It's not something 
that *some* transform functions need (in which case, it would make sense 
to add it as a parameter). It's something *all* transform functions 
need, hence it makes much more sense to be a separate property.

-- 
Lea Verou (http://lea.verou.me | @LeaVerou)

Received on Sunday, 5 February 2012 00:08:26 UTC