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

Hi Lea,

On 05/02/2012, at 3:12 AM, Lea Verou wrote:

> On 5/2/12 06:33, Dean Jackson wrote: 
>> 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? 
> 
> When did I suggest mixed commas and spaces?! I suggested it should be comma separated *instead* of space separated.

I know. I was just noting that in the meantime we'd have to support a mixed mode.

I guess if we move to comma separated lists, then we should remove the commas in the functions themselves. This is a significant change (for something that I don't think is broken).

> Everywhere in CSS, space separated means multiple values for different things (i.e. in shorthands, or in shorthand-like properties, like shadows or positions), not sequences of the same thing.

I think that describes transforms pretty well. I think of the transform property as a single transform that is described by a chain of functions. The fact that it looks like a list is to make it easier to describe a single 3x3 or 4x4 transformation matrix. (There are other benefits for the chain, especially in animation).

>> We'd have to support this mixed comma/space mode due to the amount of existing content. 
> 
> Since when is backwards compatibility an issue for WD stuff? If it was, we wouldn't have changed the way angles work in gradients either.

That's true. I expect though that we (Apple + WebKit) will never be able to break the way we parse -webkit-transform. This means we'd have to allow spaces, even if commas are added. The unprefixed version could conceivably use commas-only if the spec changes. 

> 	background-image: url(commas.png), url(are.png), url(better.png);
> 	background-position: top left, bottom left, 50% 50%;
> 
> Do you think that's not obvious either? Tough luck, cause css3-background is in CR. So, apparently, there was consensus that it is readable enough, and that kinda creates a precedent. :-)

But so does the 11 years that SVG has been a Recommendation. Up to this point I can't remember anyone saying it's confusing that there are no commas.

>> 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.
> 
> True, but order matters in shadows and backgrounds too. Each shadow is added on top of the other, same with backgrounds. So, in a way, it is cumulative there too. 

Not quite. Like I said, you do not make a shadow of a shadow. Anyway, this isn't a big deal at all.

>> 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.
> 
> Again, your gripes are about the way lists work in CSS in general,

Yes, in this case I like the simple syntax because there is no ambiguity.

I don't really want to argue this any more. I (hope I) understand your point and I agree that it is valid. I'm still on the side of space-separation but I'm ok if the WG goes the other way. But if so, then it needs to remain consistent with SVG, so I would definitely want to see the SVG Recommendation updated at the same time (of course that will be bad because it will break all SVG content that uses transforms).

This reminds me that public-fx is probably the place at which this discussion should take place. The transforms specification is now a jointly owned work between SVG and CSS.

Dean

Received on Sunday, 5 February 2012 18:13:05 UTC