Intent to implement : Unprefixed CSS Animations

[Alexis Menard]

Contact emails

alexis...@intel.com

Spec

http://www.w3.org/TR/css3-animations/

Summary

Support of unprefixed CSS properties for CSS Animations

Motivation

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 CSSPropertyNames.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)?

Yes.

OWP launch tracking bug?

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

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.

LGTY?

Thanks.

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

[Eric Seidel]

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.

[Alexis Menard]

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. http://dev.w3.org/csswg/css-animations/ also say : "No test suite". It's sad.

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.

[Julien Chaffraix]

> 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.
> http://dev.w3.org/csswg/css-animations/ also say : "No test suite". It's
> sad.

Dirk mentioned that some W3C test he was looking at importing did have
some unprefixed animations but it was fairly limited IIRC.

I am hugely supportive of unprefixing animation. I would expect a
split parsing path (no alias) to be the safest way as we don't want to
the unprefixed version to share any quirks we find along the way.

Julien

[PhistucK]

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

{

 15%

 {

  -webkit-transform: rotate(30deg);

  transform: rotate(30deg);

 }

 30%

 {

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

☆PhistucK

[Eric Seidel]

I think w/o a conformance test suite of some form, unprefixing occurs a risk of incompatible implementations.  As noted, our <canvas> implementation (being the first) was rather different from what the spec settled on.  I worry the same may have occurred here.

That said, clearly unprefixing is the end goal.  Just would be nice to be able to get there w/o breaking existing apps (which may expect the unprefixed versions to function differently than our prefixed ones do).

[Alexis Menard]

On Mon, Aug 5, 2013 at 5:34 PM, PhistucK <phis...@gmail.com> wrote:

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

{

 15%

 {

  -webkit-transform: rotate(30deg);

  transform: rotate(30deg);

 }

 30%

 {

  -webkit-transform: rotate(60deg);

  transform: rotate(30deg);

 }

}

That's valid for any prefixed property you want to animate. Sure transform is maybe very common in keyframes but still.

 

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

Unprefix then align while it's already shipping is one way to do which I do not agree with.

[PhistucK]

Well, yes, as far as I know, transform is common in keyframes. What "but still"? doing this would break compatibility. This is bad. I would definitely add that to the compatibility risks.

I am not familiar with the details ("Unprefix then align"), so I cannot comment on that.

☆PhistucK

[Shawn Singh]

Unfortunately, transforms are not ready to be unprefixed.
1. backface-visibility may not be exactly per spec yet
2. hit testing on transformed elements is not fully correct
3. chromium does not yet support layers that intersect each other.
4. possibly other issues.
5. There also seem to be a few important unresolved issues with the
spec - https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&cmdtype=doit

At least #2 and #3 above may require some pretty hefty changes. But I
think it would be important to fix these before unprefixing, so that
we do not have to maintain two separate behaviors after unprefixing.

I agree with Eric about a conformance suite, too. Last time I checked
several months ago, it seems like the W3C test cases may be in need of
some care and attention. But, I'm wondering, what would we do with a
conformance suite? Would we put it as part of blink layout tests? or
would it be something we run separately, and how would that work?

[Alexis Menard]

Ok I agree it is a compatibility risk but it's not just about transforms it's about any webkit prefixed property you used in the @-webkit-keyframes and then in the @keyframes you haven't used the prefixed counterpart.

I still can do the work and see how often the problem occurs while it's behind the flag. Then maybe we'll do an intent to implement for unprefixing the CSS Transform before the Intent to Ship on the CSS Animations. How that sounds to you?

Thanks for the feedback.

[Douglas Stockwell]

I know of a number of bugs that should be fixed before we ship this. I will mark them as blockers on the tracking bug.

But I think it's fine to start implementing this now. lgtm.

[PhistucK]

Of course, implementing behind a flag and seeing the results is always great.

Thank you for your consideration.

☆PhistucK

[Alexis Menard]

On Tue, Aug 6, 2013 at 4:29 AM, Douglas Stockwell <dstoc...@chromium.org> wrote:

I know of a number of bugs that should be fixed before we ship this. I will mark them as blockers on the tracking bug.

Great! Awesome, feel free to add them, I'll be happy to look at these. 

[hungla...@gmail.com]

Vào 02:58:48 UTC+7 Thứ Ba, ngày 06 tháng 8 năm 2013, Alexis Menard đã viết: