Implement support for unprefixed keyframes rules resolution.

Implement support for unprefixed keyframes rules resolution.

This commit implements the support for parsing and resolving unprefixed
@keyframes. The behavior is as followed :
- For a given animation name if only a @-webkit-keyframe or @keyframe
is defined then we resolve it.
- For a given animation name if both @-webkit-keyframes and @keyframes
are defined, the unprefixed version is always taken.
- As before if you define multiple time a @keyframes for the same animation
name (prefixed or not) the last declaration is resolved (as before).

This commit doesn't implement yet the CSSOM part of the @keyframes, it
will be done in a separate patch.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=156490

[eseidel, 2013-08-20 22:24:35]

I suspect that preferring the unprefixed version is correct, but will change
behavior.

If you define two @keyframes which will be taken?  It seems we should treat
unprefixed and prefixed as though they're the same thing and follow normal CSS
ordering rules?

[eseidel, 2013-08-20 22:26:31]

https://codereview.chromium.org/23264017/diff/4001/Source/core/css/CSSParser-...
File Source/core/css/CSSParser-in.cpp (right):

https://codereview.chromium.org/23264017/diff/4001/Source/core/css/CSSParser-...
Source/core/css/CSSParser-in.cpp:11207: rule->setVendorPrefixed(isPrefixed);
I really like this pattern, btw.  Of just using the same underlying logic with a
bool for "prefixed" mode.

https://codereview.chromium.org/23264017/diff/4001/Source/core/css/resolver/S...
File Source/core/css/resolver/ScopedStyleResolver.cpp (right):

https://codereview.chromium.org/23264017/diff/4001/Source/core/css/resolver/S...
Source/core/css/resolver/ScopedStyleResolver.cpp:338: if
(rule->isVendorPrefixed()) {
This is attempting to do the ordering?

[darktears, 2013-08-21 11:20:46]

On 2013/08/20 22:26:31, eseidel wrote:
>
https://codereview.chromium.org/23264017/diff/4001/Source/core/css/CSSParser-...
> File Source/core/css/CSSParser-in.cpp (right):
> 
>
https://codereview.chromium.org/23264017/diff/4001/Source/core/css/CSSParser-...
> Source/core/css/CSSParser-in.cpp:11207: rule->setVendorPrefixed(isPrefixed);
> I really like this pattern, btw.  Of just using the same underlying logic with
a
> bool for "prefixed" mode.
> 
>
https://codereview.chromium.org/23264017/diff/4001/Source/core/css/resolver/S...
> File Source/core/css/resolver/ScopedStyleResolver.cpp (right):
> 
>
https://codereview.chromium.org/23264017/diff/4001/Source/core/css/resolver/S...
> Source/core/css/resolver/ScopedStyleResolver.cpp:338: if
> (rule->isVendorPrefixed()) {
> This is attempting to do the ordering?

Indeed.

[darktears, 2013-08-21 11:27:53]

On 2013/08/20 22:24:35, eseidel wrote:
> I suspect that preferring the unprefixed version is correct, but will change
> behavior.
> 
> If you define two @keyframes which will be taken?  It seems we should treat
> unprefixed and prefixed as though they're the same thing and follow normal CSS
> ordering rules?

Yes the commit log describes the behaviour. The unprefixed version always "win"
no matter what (which is what we're doing for prefixed/unprefixed CSS
properties).

duplicated-keyframes-name-unprefixed-01.html,
duplicated-keyframes-name-unprefixed-02.html tests cover that description. Even
if you define a prefixed @-webkit-keyframes after or before a @keyframes (for
the same animation name of course), we're going to use the unprefixed
@keyframes.

duplicated-keyframes-name-unprefixed-03.html covers a tricky case. Where you
redefine a @keyframes with the same name (it will then "erase" the old version,
just like before or in a matter of fact similar to any duplicated declaration
CSS property declaration) but then after redefining it you declare a
@-webkit-keyframes with the same animation name then we should anyway care about
the *last* unprefixed @keyframes and ignore the @-webkit-keyframes added after
(again due to the fact that @keyframes takes precedence).

I hope I made it clearer.

[eseidel, 2013-08-21 19:29:52]

I appreciate your careful testing.

[eseidel, 2013-08-21 19:29:58]

lgtm

[commit-bot: I haz the power, 2013-08-21 19:30:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexis.menard@intel.com/23264017/24001

[commit-bot: I haz the power, 2013-08-21 19:36:50]

Change committed as 156490