Google Groups

Re: [blink-dev] Intent to implement : Unprefixed CSS Animations

PhistucK Aug 5, 2013 1:34 PM
Posted in group: blink-dev
I think CSS transforms and CSS animations must be unprefixed together at once.
Unless you want to end up with this kind of code (which no one does and thus would break the web) -
@keyframes bla
  -webkit-transform: rotate(30deg);
  transform: rotate(30deg);
  -webkit-transform: rotate(60deg);
  transform: rotate(30deg);

For the record, Firefox and Internet Explorer (and perhaps Opera, not sure) unprefixed all of them (including CSS transitions) at once.


On Mon, Aug 5, 2013 at 11:21 PM, Alexis Menard <> wrote:
There is no test suite (at least I'm not aware of it) beside what we have and what I will add to cover to align with the spec. also say : "No test suite". It's sad.

On Mon, Aug 5, 2013 at 5:08 PM, Eric Seidel <> wrote:
I'm supportive of this unprefixing.  Do we have a test suite to make sure that our unprefixed versions conform to it?  It took us a long time to get our <canvas> implementation to match the Canvas spec.  I suspect the same may be true for our animations during the process of unprefixing them.

On Mon, Aug 5, 2013 at 12:58 PM, Alexis Menard <> wrote:

Contact emails



Support of unprefixed CSS properties for CSS Animations


It's pretty obvious but today Blink doesn't support setting unprefixed CSS properties for the animations module. You'll have to use the -webkit-* properties to make your animations work. Supporting the unprefixed counterpart will help the web towards a better place and avoid using proprietary names. With WebKit, Blink is the only major vendor not supporting it.

Compatibility Risk

I believe that the implementation is pretty close to the spec but we need to investigate if parsing and behaviour is aligned. If we intent to change behaviour of the proprietary counterpart (in the name of sharing the code with the unprefixed part) then we potentially could break some sites around. Again based on my experience unprefixing the CSS Transitions (where I changed the behaviour to align with the spec in few cases) it doesn't seem to be an issue. It's a case by case basis that we can discuss on a given patch if the problem arise.

Ongoing technical constraints

It may sounds super easy to do like just aliasing the CSS properties in but based on the experience of CSS Transitions (where the original implementation aliased the properties) it is slightly more tricky : property counts in the declared style, prefixed/unprefixed DOM events... Luckily these problems are resolved with the work on CSS Transitions so I expect the implementation to be faster. For the record unprefixed CSS Transitions are shipping since Chrome 26.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?


OWP launch tracking bug?

Row on feature dashboard?

No. The feature is already in the engine. Should I add a row (and probably one for the CSS Transitions then)?

Requesting approval to ship?

No. I'd like to develop the change in the comfort zone like we did with the transitions properties and let the people experience it with the experimental features. When it's done then I will send an intent to ship.



Alexis Menard
Software Engineer @
Intel Open Source Technology Center

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

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.