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

On 04/02/2012, at 4:07 PM, Lea Verou wrote:

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

Sure, but I don't think they'll read this:

transform: translate(10px) scale(2) rotate(45deg)

and have any doubt what's going on. Now, compare it to this:

transform: translate(10px) scale(2), rotate(45deg)

Is that two transforms or one? What's the origin for the second? We'd have to support this mixed comma/space mode due to the amount of existing content. Now add a list into transform origin:

transform-origin: top left, bottom left, 50% 50%

Now there are clearly three things in that list - do they match the three transforms? We can work out the answer, but it isn't too obvious.

As Tab said, avoid commas (punctuation) unless there is ambiguity.

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

To be honest, we probably just thought it looked better that way. Now that you've brought it up it I do think we should have considered commas for filters to be more like other parts of CSS. There is a slight difference with filters though, in that most other places with lists (multiple backgrounds, shadows) add the effect to the source and composite together. You don't get shadows of shadows, for example. With filters and transforms it is a cumulative effect - the output of one element in the list is used as the input to the next.

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

I guess I just think that it adds more complexity than benefit. It would definitely help the situation where you have a list of transforms and you want to have different origins, but imagine this:

transform: translate scale rotate translateZ rotateY translateX rotateX;

(yes, I've written transforms like that :). Now, I want a different origin for the rotateY, but everything else is the same. Unfortunately this would produce:

transform-origin: 50% 50%, 50% 50%, 50% 50%, 50% 50%, 50% 100%, 50% 50%, 50% 50%;

I think in that case I would have been better off doing the translation myself.

An origin() function is an interesting idea. But I think it might be hard to explain. The most common case of wanting to move the origin is rotation, and I believe we have at least an informal resolution to add a point of rotation to the rotate() function (for SVG compatibility).

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

I'm not sure why animations are more difficult. If the from and to transforms have matching functions then there isn't a need for a new origin. If they're not, then now you have to set origin up twice.

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

Yes, I agree.

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

This is a good point.

Dean

Received on Sunday, 5 February 2012 04:34:32 UTC