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

On Sun, Feb 5, 2012 at 3:29 PM, Lea Verou <> wrote:
> On 5/2/12 23:56, Robert O'Callahan wrote:
>> There is a ton of usage of the unprefixed version already, and I bet
>> much of it doesn't use commas since it's just copied and pasted from
>> whatever worked in Webkit.
>> We don't have the freedom to change the unprefixed syntax in
>> incompatible ways.
> Then why did we change the gradient syntax in incompatible ways? How is that
> different?
> And what's the point of WD and prefixes if backwards compatibility is that
> big an issue even in that case? If nothing can change in transforms any
> more, why doesn't it move to CR?
> There is a recent thread on this list by Tab & fantasai about review of
> functional notation in CSS, pretty much everything suggested there would
> also break backwards compatiblity in incompatible ways just as much.

We could change gradient syntax, honestly, because I *kept changing
it*.  It never got to stabilize, and browsers implemented it at
various points, so everyone was somewhat different *anyway*.

Prefixes *generally* protect us from back-compat issues - that's the
whole point of them.  Unfortunately, Transforms (along with
Transitions and Animations) have spent *way* too long in WD.  It
should have been a CR at least a year ago, if it had been editted
actively.  At this point, its syntax is in far too wide of use to be
changed without very good reason.

I stand by what I argued before - we use commas to separate lists when
there is ambiguity, otherwise we just comma-separate.  Transforms, so
far at least, are totally unambiguous without commas.  As well, as
Dean points out, there are several places that may want to take a
"list of transforms", and if they're comma-separated it'll be harder
to include them (we'd need to do something like wrap them in another


Received on Monday, 6 February 2012 09:05:19 UTC