Add CSS Transition support to registered custom properties

Add CSS Transition support to registered custom properties

This patch updates CSSAnimations to support custom/standard property
calculation passes and updates style resolve to compute transitions
on custom properties during applyMatchedPropertiesAndCustomPropertyAnimations().

BUG=671904
Review-Url: https://codereview.chromium.org/2730683002
Cr-Commit-Position: refs/heads/master@{#456978}
Committed: https://chromium.googlesource.com/chromium/src/+/63d7497f58f29caed49491517693b392694411f5

[alancutter (OOO until 2018), 2017-03-02 06:17:51]

The CQ bit was checked by alancutter@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-02 06:18:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-02 06:22:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-02 06:22:34]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[alancutter (OOO until 2018), 2017-03-03 08:46:51]

Description was changed from

==========
WIP customTransitions

BUG=671904
==========

to

==========
Add CSS Transition support to registered custom properties

This patch updates CSSAnimations to support custom/standard property
calculation passes and updates style resolve to compute transitions
on custom properties during applyMatchedPropertiesAndCustomPropertyAnimations().

BUG=671904
==========

[alancutter (OOO until 2018), 2017-03-03 08:46:51]

alancutter@chromium.org changed reviewers:
+ ericwilligers@chromium.org

[Eric Willigers, 2017-03-08 04:10:47]

ericwilligers@chromium.org changed reviewers:
+ suzyh@chromium.org

[Eric Willigers, 2017-03-08 04:10:48]

Seems fine.

https://codereview.chromium.org/2730683002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/css/CSSPropertyEquality.cpp (right):

https://codereview.chromium.org/2730683002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/CSSPropertyEquality.cpp:11: #include
"wtf/text/AtomicString.h"
Declaring the class would be sufficient. frame/csp/ContentSecurityPolicy.h has
an example.

[alancutter (OOO until 2018), 2017-03-09 04:35:59]

https://codereview.chromium.org/2730683002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/css/CSSPropertyEquality.cpp (right):

https://codereview.chromium.org/2730683002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/CSSPropertyEquality.cpp:11: #include
"wtf/text/AtomicString.h"
On 2017/03/08 at 04:10:47, Eric Willigers wrote:
> Declaring the class would be sufficient. frame/csp/ContentSecurityPolicy.h has
an example.

Removed.

[Eric Willigers, 2017-03-09 05:21:06]

lgtm

[suzyh_UTC10 (ex-contributor), 2017-03-10 04:08:28]

So... I don't have any particular concerns about _what_ this patch does, nor is
it particularly different in style from the existing code. So my pushback here
is not so much about your patch as it is about a trend. These files are large,
and structured as big procedural "do this then this then this" code. I think
that I shouldn't really need to load in to working memory the whole of the code
to make sure that this patch makes sense, but having just reviewed this patch
without doing so, I'm not confident that I would have noticed any non-obvious
pitfalls. Now, since this is not as much a comment about your patch as about the
size of the pile you're adding to, what would you like to do here? Back up and
restructure things here? Land this functionality and then engage in
restructuring? Is this the last thing left in the custom property
animation+transition work? I think restructuring is going to need to happen in
the near future, but I'm open to negotiation about the order in which we do
stuff.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/animations/custom-properties/color-type-interpolation-expected.txt
(right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/animations/custom-properties/color-type-interpolation-expected.txt:35:
FAIL CSS Transitions: property <--color> from [black] to [currentcolor] at (0.3)
is [rgb(0, 0, 0)] assert_equals: expected "rgb ( 0 , 77 , 0 ) " but got "rgb ( 0
, 0 , 0 ) "
So it looks like this failure is in line with the failure for CSS Animations
below. But why is this the case?

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp (right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:675: //
TODO(alancutter): Support transitions on registered custom properties and
Obsolete TODO?

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:792: if
(transitionProperty.propertyType !=
This is a little confusing. Comparing it to the propertyType !=
TransitionKnownProperty below, I wonder if it would make sense to move this
check to a separate function, and have something like

calculateTransitionUpdateForProperty(..) {
  if (propertyType == TransitionKnownProperty) {
    calculateTransitionUpdateForStandardProperty();
  } else if (propertyType == TransitionUnknownProperty) {
    calculateTransitionUpdateForCustomProperty();
  }
}

If you do this, then there might be other stuff that makes sense to move into
this function, but I haven't thought about it.

Having written this comment, I then realised that
calculateTransitionUpdateForProperty already exists and is called by this. Maybe
these functions are the wrong way around, i.e. calling code should call into
calculateTransitionUpdateForProperty rather than
calculateTransitionUpdateFor*Property. I haven't looked at the calling code to
see what's easiest to read at that point.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:964: static bool
isCustomStylePropertyHandle(const PropertyHandle& property) {
I think these functions and isStylePropertyHandle belong in a util library.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:1031:
DCHECK_EQ(propertyPass, PropertyPass::Standard);
This if-else structure is a repeated pattern. Instead of an enum value guarding
two functions with very similar names, is there an alternative design using
inheritance/polymorphism?

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/animation/css/CSSAnimations.h (right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.h:81: enum class
PropertyPass { Custom, Standard };
Please add a comment to describe what this enum means.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp (right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp:1617:
(animatingElement && animatingElement->hasAnimations())) {
Devil's advocate: What does *not* trigger this if-statement to be executed?
Would this condition be shorter / clearer to read if it was something like "if
(!nothingMoves())"?

Especially since this is repeated below.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp:1710:
state.animationUpdate().activeInterpolationsForCustomTransitions());
Naming: Why ...ForCustomTransitions but ...ForAnimations above?

[alancutter (OOO until 2018), 2017-03-12 23:52:07]

On 2017/03/10 at 04:08:28, suzyh wrote:
> So... I don't have any particular concerns about _what_ this patch does, nor
is it particularly different in style from the existing code. So my pushback
here is not so much about your patch as it is about a trend. These files are
large, and structured as big procedural "do this then this then this" code. I
think that I shouldn't really need to load in to working memory the whole of the
code to make sure that this patch makes sense, but having just reviewed this
patch without doing so, I'm not confident that I would have noticed any
non-obvious pitfalls. Now, since this is not as much a comment about your patch
as about the size of the pile you're adding to, what would you like to do here?
Back up and restructure things here? Land this functionality and then engage in
restructuring? Is this the last thing left in the custom property
animation+transition work? I think restructuring is going to need to happen in
the near future, but I'm open to negotiation about the order in which we do
stuff.

I agree that CSSAnimations.cpp is in need of a clean up. I think it's
unreasonably obstructionist to think of blocking this patch on cleaning up a 1k+
line file though.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/animations/custom-properties/color-type-interpolation-expected.txt
(right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/animations/custom-properties/color-type-interpolation-expected.txt:35:
FAIL CSS Transitions: property <--color> from [black] to [currentcolor] at (0.3)
is [rgb(0, 0, 0)] assert_equals: expected "rgb ( 0 , 77 , 0 ) " but got "rgb ( 0
, 0 , 0 ) "
On 2017/03/10 at 04:08:28, suzyh wrote:
> So it looks like this failure is in line with the failure for CSS Animations
below. But why is this the case?

We compute custom properties before color (as color may depend on custom
properties) so the value of currentcolor has not been computed yet. It's unclear
how to resolve this...

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp (right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:675: //
TODO(alancutter): Support transitions on registered custom properties and
On 2017/03/10 at 04:08:28, suzyh wrote:
> Obsolete TODO?

Thanks, removed.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:792: if
(transitionProperty.propertyType !=
On 2017/03/10 at 04:08:28, suzyh wrote:
> This is a little confusing. Comparing it to the propertyType !=
TransitionKnownProperty below, I wonder if it would make sense to move this
check to a separate function, and have something like
> 
> calculateTransitionUpdateForProperty(..) {
>   if (propertyType == TransitionKnownProperty) {
>     calculateTransitionUpdateForStandardProperty();
>   } else if (propertyType == TransitionUnknownProperty) {
>     calculateTransitionUpdateForCustomProperty();
>   }
> }
> 
> If you do this, then there might be other stuff that makes sense to move into
this function, but I haven't thought about it.
> 
> Having written this comment, I then realised that
calculateTransitionUpdateForProperty already exists and is called by this. Maybe
these functions are the wrong way around, i.e. calling code should call into
calculateTransitionUpdateForProperty rather than
calculateTransitionUpdateFor*Property. I haven't looked at the calling code to
see what's easiest to read at that point.

I put this logic here because it's specific to custom properties and to avoid
adding too much to the call site calculateTransitionUpdate().
I'm open to naming suggestions, I agree the current names are a bit backwards
when viewed together but it's hard to come up with alternatives, in isolation
they are accurate names.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:964: static bool
isCustomStylePropertyHandle(const PropertyHandle& property) {
On 2017/03/10 at 04:08:28, suzyh wrote:
> I think these functions and isStylePropertyHandle belong in a util library.

I disagree. They're only used in one file and they don't have any utility
elsewhere. Other places just call property.isCSSCustomProperty().

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:1031:
DCHECK_EQ(propertyPass, PropertyPass::Standard);
On 2017/03/10 at 04:08:28, suzyh wrote:
> This if-else structure is a repeated pattern. Instead of an enum value
guarding two functions with very similar names, is there an alternative design
using inheritance/polymorphism?

I could create a strategy pattern here though it would require defining three
new classes. I don't think the boilerplate and code indirection for the reader
is worth it. Perhaps if this were intended to grow more branches in future but
that's not the case here.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/animation/css/CSSAnimations.h (right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/css/CSSAnimations.h:81: enum class
PropertyPass { Custom, Standard };
On 2017/03/10 at 04:08:28, suzyh wrote:
> Please add a comment to describe what this enum means.

Done.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp (right):

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp:1617:
(animatingElement && animatingElement->hasAnimations())) {
On 2017/03/10 at 04:08:28, suzyh wrote:
> Devil's advocate: What does *not* trigger this if-statement to be executed?
Would this condition be shorter / clearer to read if it was something like "if
(!nothingMoves())"?
> 
> Especially since this is repeated below.

We can't early exit on the negation here because there's still more work to do
after the if.
I don't think double negating it:
(!(!state.style()->animations() && !state.style()->transitions() &&
(!animatingElement || !animatingElement->hasAnimations())))
is clearer than it currently is.

https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp:1710:
state.animationUpdate().activeInterpolationsForCustomTransitions());
On 2017/03/10 at 04:08:28, suzyh wrote:
> Naming: Why ...ForCustomTransitions but ...ForAnimations above?

CSS Transitions has separate custom/standard computation passes that use
separate interpolation storage buckets, this is not the case for CSS Animations.

[suzyh_UTC10 (ex-contributor), 2017-03-13 00:16:05]

lgtm to unblock since I'm out sick and can't give a good turnaround. If in doubt
get another review from Shane or someone before landing.


On 2017/03/12 at 23:52:07, alancutter wrote:
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > So... I don't have any particular concerns about _what_ this patch does, nor
is it particularly different in style from the existing code. So my pushback
here is not so much about your patch as it is about a trend. These files are
large, and structured as big procedural "do this then this then this" code. I
think that I shouldn't really need to load in to working memory the whole of the
code to make sure that this patch makes sense, but having just reviewed this
patch without doing so, I'm not confident that I would have noticed any
non-obvious pitfalls. Now, since this is not as much a comment about your patch
as about the size of the pile you're adding to, what would you like to do here?
Back up and restructure things here? Land this functionality and then engage in
restructuring? Is this the last thing left in the custom property
animation+transition work? I think restructuring is going to need to happen in
the near future, but I'm open to negotiation about the order in which we do
stuff.
> 
> I agree that CSSAnimations.cpp is in need of a clean up. I think it's
unreasonably obstructionist to think of blocking this patch on cleaning up a 1k+
line file though.

Sure. Is cleaning up CSSAnimations.cpp the next thing to do, or is there more
that you need to do on custom property work that you want to do first?


>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Layo...
> File
third_party/WebKit/LayoutTests/animations/custom-properties/color-type-interpolation-expected.txt
(right):
> 
>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Layo...
>
third_party/WebKit/LayoutTests/animations/custom-properties/color-type-interpolation-expected.txt:35:
FAIL CSS Transitions: property <--color> from [black] to [currentcolor] at (0.3)
is [rgb(0, 0, 0)] assert_equals: expected "rgb ( 0 , 77 , 0 ) " but got "rgb ( 0
, 0 , 0 ) "
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > So it looks like this failure is in line with the failure for CSS Animations
below. But why is this the case?
> 
> We compute custom properties before color (as color may depend on custom
properties) so the value of currentcolor has not been computed yet. It's unclear
how to resolve this...

Hm, sounds like that's going to need some thought in the next pass.


>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp (right):
> 
>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:675: //
TODO(alancutter): Support transitions on registered custom properties and
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > Obsolete TODO?
> 
> Thanks, removed.
> 
>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:792: if
(transitionProperty.propertyType !=
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > This is a little confusing. Comparing it to the propertyType !=
TransitionKnownProperty below, I wonder if it would make sense to move this
check to a separate function, and have something like
> > 
> > calculateTransitionUpdateForProperty(..) {
> >   if (propertyType == TransitionKnownProperty) {
> >     calculateTransitionUpdateForStandardProperty();
> >   } else if (propertyType == TransitionUnknownProperty) {
> >     calculateTransitionUpdateForCustomProperty();
> >   }
> > }
> > 
> > If you do this, then there might be other stuff that makes sense to move
into this function, but I haven't thought about it.
> > 
> > Having written this comment, I then realised that
calculateTransitionUpdateForProperty already exists and is called by this. Maybe
these functions are the wrong way around, i.e. calling code should call into
calculateTransitionUpdateForProperty rather than
calculateTransitionUpdateFor*Property. I haven't looked at the calling code to
see what's easiest to read at that point.
> 
> I put this logic here because it's specific to custom properties and to avoid
adding too much to the call site calculateTransitionUpdate().
> I'm open to naming suggestions, I agree the current names are a bit backwards
when viewed together but it's hard to come up with alternatives, in isolation
they are accurate names.

OK, let's look at it when we go to clean up this code.


>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:964: static
bool isCustomStylePropertyHandle(const PropertyHandle& property) {
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > I think these functions and isStylePropertyHandle belong in a util library.
> 
> I disagree. They're only used in one file and they don't have any utility
elsewhere. Other places just call property.isCSSCustomProperty().

Fair. It's an easy way to reduce the size of the file though, so consider it
when looking at cleaning up the file.


>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/animation/css/CSSAnimations.cpp:1031:
DCHECK_EQ(propertyPass, PropertyPass::Standard);
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > This if-else structure is a repeated pattern. Instead of an enum value
guarding two functions with very similar names, is there an alternative design
using inheritance/polymorphism?
> 
> I could create a strategy pattern here though it would require defining three
new classes. I don't think the boilerplate and code indirection for the reader
is worth it. Perhaps if this were intended to grow more branches in future but
that's not the case here.
> 
>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/animation/css/CSSAnimations.h (right):
> 
>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/animation/css/CSSAnimations.h:81: enum class
PropertyPass { Custom, Standard };
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > Please add a comment to describe what this enum means.
> 
> Done.
> 
>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp (right):
> 
>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp:1617:
(animatingElement && animatingElement->hasAnimations())) {
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > Devil's advocate: What does *not* trigger this if-statement to be executed?
Would this condition be shorter / clearer to read if it was something like "if
(!nothingMoves())"?
> > 
> > Especially since this is repeated below.
> 
> We can't early exit on the negation here because there's still more work to do
after the if.
> I don't think double negating it:
> (!(!state.style()->animations() && !state.style()->transitions() &&
(!animatingElement || !animatingElement->hasAnimations())))
> is clearer than it currently is.

I didn't actually mean double negation at this site, but to hide the complexity
of the condition behind a helper function with an informative name, for the
purposes of making the logic of the code more apparent in a quick read.


>
https://codereview.chromium.org/2730683002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp:1710:
state.animationUpdate().activeInterpolationsForCustomTransitions());
> On 2017/03/10 at 04:08:28, suzyh wrote:
> > Naming: Why ...ForCustomTransitions but ...ForAnimations above?
> 
> CSS Transitions has separate custom/standard computation passes that use
separate interpolation storage buckets, this is not the case for CSS Animations.

Ack.

[alancutter (OOO until 2018), 2017-03-15 01:53:35]

> Is cleaning up CSSAnimations.cpp the next thing to do, or is there more that
you need to do on custom property work that you want to do first?

There's still the var() references in registered custom property animation
keyframes to do and extended syntax type support.

[alancutter (OOO until 2018), 2017-03-15 01:54:01]

The CQ bit was checked by alancutter@chromium.org

[alancutter (OOO until 2018), 2017-03-15 01:54:02]

The patchset sent to the CQ was uploaded after l-g-t-m from
ericwilligers@chromium.org
Link to the patchset: https://codereview.chromium.org/2730683002/#ps100001
(title: "comments")

[commit-bot: I haz the power, 2017-03-15 01:54:38]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-15 03:21:28]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1489542841956500,
"parent_rev": "4a7f14f6f4b33edc609ffda8b980057b71ef75be", "commit_rev":
"63d7497f58f29caed49491517693b392694411f5"}

[commit-bot: I haz the power, 2017-03-15 03:23:08]

Description was changed from

==========
Add CSS Transition support to registered custom properties

This patch updates CSSAnimations to support custom/standard property
calculation passes and updates style resolve to compute transitions
on custom properties during applyMatchedPropertiesAndCustomPropertyAnimations().

BUG=671904
==========

to

==========
Add CSS Transition support to registered custom properties

This patch updates CSSAnimations to support custom/standard property
calculation passes and updates style resolve to compute transitions
on custom properties during applyMatchedPropertiesAndCustomPropertyAnimations().

BUG=671904

Review-Url: https://codereview.chromium.org/2730683002
Cr-Commit-Position: refs/heads/master@{#456978}
Committed:
https://chromium.googlesource.com/chromium/src/+/63d7497f58f29caed49491517693...
==========

[commit-bot: I haz the power, 2017-03-15 03:23:10]

Committed patchset #6 (id:100001) as
https://chromium.googlesource.com/chromium/src/+/63d7497f58f29caed49491517693...