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

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

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

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

Also, with the change I'm suggesting, we could go even further and make `transform` a shorthand of `transform-function` and `transform-origin`. Commas would make even more sense in that case, and it would enable transforms to be more compact and consistent with the rest of the language.

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

	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. :-)
 
> 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. 
Also, I don't think it's a large enough difference to warrant teaching people that there are two kinds of lists in CSS: Comma separated and space separated and that they have to remember which properties accept which kind. 

Also, if the CSS WG eventually devises a mechanism for partially overriding lists (which I think everyone agrees is needed, but there are no good ideas about how to solve it yet), it might not apply to that kind of lists, even though partial overrides are often needed here too.

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

Again, your gripes are about the way lists work in CSS in general, it applies perfectly to the `background-*` longhands too.


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

Received on Sunday, 5 February 2012 11:13:04 UTC