Removing the prefix -webkit-transform

[Adam Barth]

Does anyone know what it would take to remove the vendor prefix from -webkit-transform?  It's a very popular property.  We should figure out what we need to do in order to remove the prefix.  I've filed a bug to track this issue:

https://code.google.com/p/chromium/issues/detail?id=347396

Adam

[Douglas Stockwell]

I had started working on this. Hoping to get back to it and send an intent soon:

https://codereview.chromium.org/98663004/

[Adam Barth]

Thanks for working on this issue!  Do you know if we need to change our behavior at all to match the spec?

Adam

[Eric Seidel]

My understanding is that the core issue is that we don't currently
treat -webkit-foo and foo separately in our engine. We should. We
should parse them as different, and cannonicalize them to a single
value at a separate stage in the pipeline.

Once we do that, it should be possible to UseCounter what pages use
-webkit-foo w/o using foo, or override foo with a different value in
-webkit-foo, etc.

From the looks of that CL, it looks like Doug is already aware of this.

[Rik Cabanier]

On Wed, Feb 26, 2014 at 7:03 PM, Adam Barth <aba...@chromium.org> wrote:

Thanks for working on this issue!  Do you know if we need to change our behavior at all to match the spec?

Matrix decomposition was changed a couple of months ago to match Safari and have more intuitive behavior (ie 2D animation will no longer appear to use 3D under certain circumstances)

Simon Fraser is also working on an improved version of transform-style [1]. His proposal clears up what element creates a 3d world and how the box model is supposed to work when you have 3d transforms.

 

On Wed, Feb 26, 2014 at 6:21 PM, Douglas Stockwell <dstoc...@google.com> wrote:

I had started working on this. Hoping to get back to it and send an intent soon:

https://codereview.chromium.org/98663004/

On Thu, Feb 27, 2014 at 11:18 AM, Adam Barth <aba...@chromium.org> wrote:

Does anyone know what it would take to remove the vendor prefix from -webkit-transform?  It's a very popular property.  We should figure out what we need to do in order to remove the prefix.  I've filed a bug to track this issue:

https://code.google.com/p/chromium/issues/detail?id=347396

 

1: https://docs.google.com/document/d/1mNF7Z67WnnV05RqXa37PmfvRbgAZwj7-h-7Y_uQ_UPE/edit?pli=1#

[Adam Barth]

I'm not sure I understand...  You're saying we can't add support for unprefixed transform because it parses differently than -web kits transform?

Adam

[Rik Cabanier]

On Wed, Feb 26, 2014 at 7:18 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Wed, Feb 26, 2014 at 7:03 PM, Adam Barth <aba...@chromium.org> wrote:

Thanks for working on this issue!  Do you know if we need to change our behavior at all to match the spec?

Matrix decomposition was changed a couple of months ago to match Safari and have more intuitive behavior (ie 2D animation will no longer appear to use 3D under certain circumstances)

Simon Fraser is also working on an improved version of transform-style [1]. His proposal clears up what element creates a 3d world and how the box model is supposed to work when you have 3d transforms.

One other things that changed quite a while ago, is that opacity will cause the transform-style to always be 'flat'.

So, the non-prefixed version of transform should render http://www.webkit.org/blog-files/3d-transforms/transform-style.html differently.

[Douglas Stockwell]

I'm not aware of any parsing differences yet. We implement -webkit-transform-origin as a shorthand, but transform-origin is not a shorthand in css3-transforms, it appears this can be worked around without too much effort.

Shawn raised some issues last time this discussion came up which are summarized in the bug.

There's also a test suite for the spec (http://test.csswg.org/suites/css3-transforms/nightly-unstable/) that I was planning to look through once I have the basics working.

[Dirk Schulze]

Rik is correct, the CSS WG is discussing some changes to CSS Transforms that makes CSS Transforms easier to use for authors, the overall spec text much more sane and allows UAs to be interoperable. These changes mainly affect the preserve 3d behavior.

This might require smaller changes to the syntax of transform-origin.

Blink could fix prefixed and unprefixed transform together. Based on our previous discussions (e.g -webkit-clip-path) it seems that for Blink it is preferred to not touch the prefixed version but do the changes in the unprefixed version instead.

I am not sure if the unprefixed version for transform already exists in Blink. If it doesn’t, it might be wise to flag the unprefixed version until everything is implemented correctly and the changes for CSS Transforms were approved by the CSS WG and other UAs.

Greetings,
Dirk

[Alexis Menard]

Hi Eric,

This is not really accurate. One may use the alias "=" in CSSPropertyNames.in and then the engine becomes unaware if you parse -webkit-* or * property. 

This is not the approach we've been taking for the animations and the transitions because we needed to know wether we parse one or the other to dispatch the prefixed/unprefixed DOM events correctly. At style resolution we only resolve one set of them which make the entire thing work (note that we do not have behaviour difference between the prefixed and unprefixed animations and transitions).

When unprefixing the transforms we can choose one way or the other so you can make the parsing/resolving different for the prefixed version if you want to. There is no technical blocker that I'm aware atm.

Concerning the discussions going on in the W3C, I think we should keep align the prefixed and the unprefixed versions anyway.

Thanks. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
Alexis Menard
Software Engineer @
Intel Open Source Technology Center

Intel Semiconductores do Brasil Ltda.
Ave Dr. Chucri Zaidan, 940, Brooklin, 10 Andar
04583-904 São Paulo, SP
Brazil

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

[Eric Seidel]

Correct, it's exactly "alias=" that I'm referring to. We can't use
alias= if we want to treat prefixed and unprefixed properties
separately, e.g.:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/CSSPropertyNames.in&q=CSSPropertyNames.&sq=package:chromium&l=408

When we use alias, then the string -> ID lookup is where the translation occurs:
https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/blink/CSSPropertyNames.cpp&sq=package:chromium&rcl=1393469619&l=2323&type=cs

Eventually I would like to fix alias= so that we can still use its
convenience, but that we can do the cannonicalization later, after we
use-counter the property.

Properties are later parsed based on their enum ID, so unless we
manually split them (not using alias), we can't parse them
differently:
https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/blink/BisonCSSParser.cpp&q=CSSPropertyShapeInside&sq=package:chromium&l=2666&type=cs

But then when we do that, these CSSPropertyIds are used in many places
in our engine, and we have to be careful to always make them the same.
I think to make "alias=" work better, we should separate our parse
ids from our engine ids, and map from parse ids to engine ids at some
point after use counting, before CSSProperty creation.

But as you say, we can currently work around this limitation of alias
by just specifying -webkit-transform and transform separately in
CSSPropertyNames.in and treating them as wholly separate properties
throughout the entire engine.

[Mike Lawther]

Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/

[Dirk Schulze]

On Mar 20, 2014, at 12:15 AM, Mike Lawther <mikel...@chromium.org> wrote:

> Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/

As Rik mentioned, Simon Fraser and I worked on a new proposal for transform-style that should help to make implementations more interoperable for 3D transforms. (2D transforms should already be widely interoperable.) Simon spend efforts to write down the proposed specification text.

The proposal needs review and I encourage everyone to look at and review it[1]. Independently of the proposal a thread started at www-style[2].

I would suggest to proceed with one of the two following strategies:

1) Make -webkit-transform interoperable and unprefix afterwards.
2) Unprefix now but behind the experimental runtime flag. transform and -webkit-transform could be fixed together or individually.

I think authors should be able to rely on stable unprefixed properties to limit the burden for developers in the long term.

Greetings,
Dirk

[1] https://docs.google.com/document/d/1mNF7Z67WnnV05RqXa37PmfvRbgAZwj7-h-7Y_uQ_UPE/edit?pli=1#
[2] http://lists.w3.org/Archives/Public/www-style/2014Feb/0709.html

[Adam Barth]

On Fri Mar 21 2014 at 1:34:14 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Mar 20, 2014, at 12:15 AM, Mike Lawther <mikel...@chromium.org> wrote:

> Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/

As Rik mentioned, Simon Fraser and I worked on a new proposal for transform-style that should help to make implementations more interoperable for 3D transforms.

Do you have a link that describes what the interoperability issues were?  Specifically, which inputs to which browsers produced what differences in output?

(2D transforms should already be widely interoperable.) Simon spend efforts to write down the proposed specification text.

The proposal needs review and I encourage everyone to look at and review it[1]. Independently of the proposal a thread started at www-style[2].

I would suggest to proceed with one of the two following strategies:

1) Make -webkit-transform interoperable and unprefix afterwards.
2) Unprefix now but behind the experimental runtime flag. transform and -webkit-transform could be fixed together or individually.

I think authors should be able to rely on stable unprefixed properties to limit the burden for developers in the long term.

Given that Firefox has already shipped unprefix transform and authors have been using unprefixed versions of these properties for many years, we should probably treat transform as a de facto standard rather than a de jure standard.

If there are tests that show that our implementation doesn't interoperate with Firefox's implementation, those are likely worth fixing, but I don't think we should block this work on de jure standards.

Adam

[Rik Cabanier]

On Fri, Mar 21, 2014 at 6:16 AM, Adam Barth <aba...@google.com> wrote:

On Fri Mar 21 2014 at 1:34:14 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Mar 20, 2014, at 12:15 AM, Mike Lawther <mikel...@chromium.org> wrote:

> Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/

As Rik mentioned, Simon Fraser and I worked on a new proposal for transform-style that should help to make implementations more interoperable for 3D transforms.

Do you have a link that describes what the interoperability issues were?  Specifically, which inputs to which browsers produced what differences in output?

For matrix decomposition, here's an example page with a bunch of CSS animations that looks different in every browser:

http://jsfiddle.net/cabanier/Vv84m/embedded/result/ 

I believe that this is the only issue for 2D transforms. 

This is a minor issue since not many people interpolate matrices.

3D transforms are in much worse shape. At the Seattle F2F DirkS and SimonF had example pages where very basic content displayed wildly different. They didn't post those examples yet.

There is a document that describes what some of the issues are: https://docs.google.com/document/d/1mNF7Z67WnnV05RqXa37PmfvRbgAZwj7-h-7Y_uQ_UPE/edit?pli=1#

This is a bigger problem because 3D transforms are used a lot and this proposal would change the behavior.

http://codepen.io/adobe/pen/CynLr/ is a small example. It doesn't work at all in IE, doesn't apply perspective in FF and the opacity is treated incorrectly in WK and Blink.

(2D transforms should already be widely interoperable.) Simon spend efforts to write down the proposed specification text.

The proposal needs review and I encourage everyone to look at and review it[1]. Independently of the proposal a thread started at www-style[2].

I would suggest to proceed with one of the two following strategies:

1) Make -webkit-transform interoperable and unprefix afterwards.
2) Unprefix now but behind the experimental runtime flag. transform and -webkit-transform could be fixed together or individually.

I think authors should be able to rely on stable unprefixed properties to limit the burden for developers in the long term.

Given that Firefox has already shipped unprefix transform and authors have been using unprefixed versions of these properties for many years, we should probably treat transform as a de facto standard rather than a de jure standard.

For 2D, I think we're pretty much there and have good interoperability. 

3D, there is still some work to do.

I agree that these issues should have been addressed by now... 

[Adam Barth]

On Fri Mar 21 2014 at 9:54:26 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Fri, Mar 21, 2014 at 6:16 AM, Adam Barth <aba...@google.com> wrote:

On Fri Mar 21 2014 at 1:34:14 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Mar 20, 2014, at 12:15 AM, Mike Lawther <mikel...@chromium.org> wrote:

> Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/

As Rik mentioned, Simon Fraser and I worked on a new proposal for transform-style that should help to make implementations more interoperable for 3D transforms.

Do you have a link that describes what the interoperability issues were?  Specifically, which inputs to which browsers produced what differences in output?

For matrix decomposition, here's an example page with a bunch of CSS animations that looks different in every browser:

http://jsfiddle.net/cabanier/Vv84m/embedded/result/ 

I believe that this is the only issue for 2D transforms. 

This is a minor issue since not many people interpolate matrices.

Interesting.  Thanks for the examples.

3D transforms are in much worse shape. At the Seattle F2F DirkS and SimonF had example pages where very basic content displayed wildly different. They didn't post those examples yet.

There is a document that describes what some of the issues are: https://docs.google.com/document/d/1mNF7Z67WnnV05RqXa37PmfvRbgAZwj7-h-7Y_uQ_UPE/edit?pli=1#

This is a bigger problem because 3D transforms are used a lot and this proposal would change the behavior.

http://codepen.io/adobe/pen/CynLr/ is a small example. It doesn't work at all in IE, doesn't apply perspective in FF and the opacity is treated incorrectly in WK and Blink.

Yikes, that does seem worth fixing.  I definitely agree that we should fix these issues, but I'm not sure we need to gate unprefixing transform on fixing these issues.  Many, many web sites use both prefixed and unprefixed transform properties with identical values, which means supporting the unprefixed version isn't likely to lead to more compatibility constraints than we have already.

Adam

[Dirk Schulze]

On Mar 21, 2014, at 6:08 PM, Adam Barth <aba...@google.com> wrote:

> On Fri Mar 21 2014 at 9:54:26 AM, Rik Cabanier <caba...@gmail.com> wrote:
> On Fri, Mar 21, 2014 at 6:16 AM, Adam Barth <aba...@google.com> wrote:
> On Fri Mar 21 2014 at 1:34:14 AM, Dirk Schulze <dsch...@chromium.org> wrote:
>
> On Mar 20, 2014, at 12:15 AM, Mike Lawther <mikel...@chromium.org> wrote:
>
> > Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/
>
> As Rik mentioned, Simon Fraser and I worked on a new proposal for transform-style that should help to make implementations more interoperable for 3D transforms.
>
> Do you have a link that describes what the interoperability issues were? Specifically, which inputs to which browsers produced what differences in output?
>
> For matrix decomposition, here's an example page with a bunch of CSS animations that looks different in every browser:
> http://jsfiddle.net/cabanier/Vv84m/embedded/result/
> I believe that this is the only issue for 2D transforms.
> This is a minor issue since not many people interpolate matrices.
>
> Interesting. Thanks for the examples.
>
> 3D transforms are in much worse shape. At the Seattle F2F DirkS and SimonF had example pages where very basic content displayed wildly different. They didn't post those examples yet.
> There is a document that describes what some of the issues are: https://docs.google.com/document/d/1mNF7Z67WnnV05RqXa37PmfvRbgAZwj7-h-7Y_uQ_UPE/edit?pli=1#
> This is a bigger problem because 3D transforms are used a lot and this proposal would change the behavior.
> http://codepen.io/adobe/pen/CynLr/ is a small example. It doesn't work at all in IE, doesn't apply perspective in FF and the opacity is treated incorrectly in WK and Blink.
>
> Yikes, that does seem worth fixing. I definitely agree that we should fix these issues, but I'm not sure we need to gate unprefixing transform on fixing these issues. Many, many web sites use both prefixed and unprefixed transform properties with identical values, which means supporting the unprefixed version isn't likely to lead to more compatibility constraints than we have already.

As long as Blink will make transform conform to the final specification eventually, there is no strong opinion from me.

Greetings,
Dirk

[Adam Barth]

On Fri Mar 21 2014 at 10:36:01 AM, Dirk Schulze <dsch...@chromium.org> wrote:

As long as Blink will make transform conform to the final specification eventually, there is no strong opinion from me.

We're happy to do that assuming the specification is compatible with existing content.  Given that the authors of the specification have similar compatibility constraints to ours, I'm hopeful we'll be able to converge on interoperable behavior.

Thanks,

Adam

[Rik Cabanier]

On Fri, Mar 21, 2014 at 10:41 AM, Adam Barth <aba...@google.com> wrote:

On Fri Mar 21 2014 at 10:36:01 AM, Dirk Schulze <dsch...@chromium.org> wrote:

As long as Blink will make transform conform to the final specification eventually, there is no strong opinion from me.

We're happy to do that assuming the specification is compatible with existing content.  

this will not be the case since the transform-style property will have a different initial value of 'auto'.

By not changing to this new value until removing the prefix, you won't break existing content. If you remove the prefix now, you won't be able to make that change later.

[Dirk Schulze]

Believe me that it is a main goal of the specification to assure compatibility to interoperable behavior. (See controversial proposal to change computed value of transform to UA behavior[1]). What Rik was saying is that there just is no interoperability for transform-style across browsers.

Greetings,
Dirk

[1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0317.html


> Thanks,
> Adam
>

[Adam Barth]

On Fri Mar 21 2014 at 10:48:17 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Fri, Mar 21, 2014 at 10:41 AM, Adam Barth <aba...@google.com> wrote:

We're happy to do that assuming the specification is compatible with existing content.  

this will not be the case since the transform-style property will have a different initial value of 'auto'.

Hopefully content doesn't rely on this difference.  If there's a substantial amount of code that relies on the old behavior, then browser vendors won't be able to adopt the change.

 

By not changing to this new value until removing the prefix, you won't break existing content. If you remove the prefix now, you won't be able to make that change later.

I don't think that's really true.  It's wishful thinking that vendor prefixes give you the freedom to change APIs after shipping them.  In practice, many, many web site spam the unprefixed property name with the same value they use in the prefixed version.  That means they expect the unprefixed version to work the same way as the prefixed version.

On Fri Mar 21 2014 at 10:50:07 AM, Dirk Schulze <dsch...@chromium.org> wrote:

Believe me that it is a main goal of the specification to assure compatibility to interoperable behavior.

Those are my favorite kinds of specifications.  :)

 

(See controversial proposal to change computed value of transform to UA behavior[1]). What Rik was saying is that there just is no interoperability for transform-style across browsers.

Hopefully that's a sign that content doesn't have a strong dependency one way or the other.  As long as that's the case, we still have the freedom to change the behavior.

Adam

[Rik Cabanier]

On Fri, Mar 21, 2014 at 11:00 AM, Adam Barth <aba...@google.com> wrote:

On Fri Mar 21 2014 at 10:48:17 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Fri, Mar 21, 2014 at 10:41 AM, Adam Barth <aba...@google.com> wrote:

We're happy to do that assuming the specification is compatible with existing content.  

this will not be the case since the transform-style property will have a different initial value of 'auto'.

Hopefully content doesn't rely on this difference.  If there's a substantial amount of code that relies on the old behavior, then browser vendors won't be able to adopt the change.

 

By not changing to this new value until removing the prefix, you won't break existing content. If you remove the prefix now, you won't be able to make that change later.

I don't think that's really true.  It's wishful thinking that vendor prefixes give you the freedom to change APIs after shipping them.  In practice, many, many web site spam the unprefixed property name with the same value they use in the prefixed version.  That means they expect the unprefixed version to work the same way as the prefixed version.

Yes, prefixes were never intended to be used for shipping code. It's great that FF and Blink are moving away from them.

Thinking about this new initial value some more, it is likely that it won't break most content since authors are putting preserve-3d on everything to preserve the 3d effect.

Is it possible to put the dropping of the prefix as an experimental feature first? Maybe this is too hard and we just have to test some pages in chromium once the patch lands...

[Mike Lawther]

On 22 March 2014 03:54, Rik Cabanier <caba...@gmail.com> wrote:

On Fri, Mar 21, 2014 at 6:16 AM, Adam Barth <aba...@google.com> wrote:

On Fri Mar 21 2014 at 1:34:14 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Mar 20, 2014, at 12:15 AM, Mike Lawther <mikel...@chromium.org> wrote:

> Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/

As Rik mentioned, Simon Fraser and I worked on a new proposal for transform-style that should help to make implementations more interoperable for 3D transforms.

Do you have a link that describes what the interoperability issues were?  Specifically, which inputs to which browsers produced what differences in output?

For matrix decomposition, here's an example page with a bunch of CSS animations that looks different in every browser:

http://jsfiddle.net/cabanier/Vv84m/embedded/result/ 

I believe that this is the only issue for 2D transforms. 

This is a minor issue since not many people interpolate matrices.

Yep - we've seen the transform list/matrix interpolation issue (eg https://code.google.com/p/chromium/issues/detail?id=267348) :) I did a short presentation on this as part of an animations talk at BlinkOn last September. 

There was also discussion at a CSS WG about trying to make transform lists easier to interpolate (http://lists.w3.org/Archives/Public/www-style/2013Sep/0472.html), but I'm not sure if there has been any concrete spec or implementation activity arising from that.

[Rik Cabanier]

On Sun, Mar 23, 2014 at 4:23 PM, Mike Lawther <mikel...@google.com> wrote:

On 22 March 2014 03:54, Rik Cabanier <caba...@gmail.com> wrote:

On Fri, Mar 21, 2014 at 6:16 AM, Adam Barth <aba...@google.com> wrote:

On Fri Mar 21 2014 at 1:34:14 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Mar 20, 2014, at 12:15 AM, Mike Lawther <mikel...@chromium.org> wrote:

> Doug has a patch that's ready for review: https://codereview.chromium.org/98663004/

As Rik mentioned, Simon Fraser and I worked on a new proposal for transform-style that should help to make implementations more interoperable for 3D transforms.

Do you have a link that describes what the interoperability issues were?  Specifically, which inputs to which browsers produced what differences in output?

For matrix decomposition, here's an example page with a bunch of CSS animations that looks different in every browser:

http://jsfiddle.net/cabanier/Vv84m/embedded/result/ 

I believe that this is the only issue for 2D transforms. 

This is a minor issue since not many people interpolate matrices.

Yep - we've seen the transform list/matrix interpolation issue (eg https://code.google.com/p/chromium/issues/detail?id=267348) :) I did a short presentation on this as part of an animations talk at BlinkOn last September. 

Do you have a link to that presentation?

Dirk and I updated the transforms spec so if you follow it, you should get the same behavior as Safari which most people seemed to prefer.

FWIW I wrote a patch for Firefox to do the same (https://bugzilla.mozilla.org/show_bug.cgi?id=937494)

 

There was also discussion at a CSS WG about trying to make transform lists easier to interpolate (http://lists.w3.org/Archives/Public/www-style/2013Sep/0472.html), but I'm not sure if there has been any concrete spec or implementation activity arising from that.

Yes, since no one has made a concrete proposal or done an implementation, this is separate from the removal of the prefix.

[Mike Lawther]

On 24 March 2014 10:55, Rik Cabanier <caba...@gmail.com> wrote:

On Sun, Mar 23, 2014 at 4:23 PM, Mike Lawther <mikel...@google.com> wrote:

On 22 March 2014 03:54, Rik Cabanier <caba...@gmail.com> wrote:

For matrix decomposition, here's an example page with a bunch of CSS animations that looks different in every browser:

http://jsfiddle.net/cabanier/Vv84m/embedded/result/ 

I believe that this is the only issue for 2D transforms. 

This is a minor issue since not many people interpolate matrices.

Yep - we've seen the transform list/matrix interpolation issue (eg https://code.google.com/p/chromium/issues/detail?id=267348) :) I did a short presentation on this as part of an animations talk at BlinkOn last September. 

Do you have a link to that presentation?

No, sorry. It was only a few minutes worth, and consisted of a demonstration of the samples in https://code.google.com/p/chromium/issues/detail?id=267348 and https://code.google.com/p/chromium/issues/detail?id=270321, and a look at the relevant specs, followed by some discussion amongst the attendees. The interpolation discussion at least ended with Tab going to take a proposal to the CSS WG, which as you note below, has not resulted in anything concrete.

 

Dirk and I updated the transforms spec so if you follow it, you should get the same behavior as Safari which most people seemed to prefer.

FWIW I wrote a patch for Firefox to do the same (https://bugzilla.mozilla.org/show_bug.cgi?id=937494)

Thanks for the link, we'll check it out. 

    mike

[Tab Atkins Jr.]

On Sun, Mar 23, 2014 at 4:23 PM, Mike Lawther <mikel...@google.com> wrote:

> There was also discussion at a CSS WG about trying to make transform lists
> easier to interpolate
> (http://lists.w3.org/Archives/Public/www-style/2013Sep/0472.html), but I'm
> not sure if there has been any concrete spec or implementation activity
> arising from that.

It was discussed at the Paris CSSWG f2f mid-last year, but I haven't
made a concrete proposal yet.

(The proposal is to add commas to the syntax, so that you interpolate
per comma-separated group. This isn't very useful until you get the
ability to target individual comma-separated groups, which is a
separate proposal I haven't been able to make yet, but which has been
long-standing in the CSSWG.)

~TJ