[css-variables] Animation tainting - proposed change

Hi list,


In the spirit of proposing changes to custom properties after multiple
implementations have already shipped, I’d like to suggest we change the way
that we deal with animations and tainting.

However! Unlike the other proposals, I think this one actually has a chance
of being backwards compatible..


At the moment, when a custom property is defined inside animation
keyframes, that property name is tainted. This prevents situations like:

@keyframes bob {

 0% { --duration: 10s; }

 100% { --duration: 20s; }


.foo {

 animation: bob var(--duration);


However, the property name is tainted regardless of the actual existence of
a dependency cycle. When I spoke to Tab about this, he indicated that we
went with this tainting approach to keep things simple for implementers,
despite the rule being a bit strange for users - justified as this is a
fairly minor edge case.


As an implementer, I don’t find this approach particularly simple. It will
require us to keep a document-scoped list of tainted names, and reference
them on every variable resolution that applies to an animation or
transition property.

Worse, for this to actually work as intended it needs to be transitive -
i.e. if we have

 --fran: var(--bob);

Then --fran is tainted too. So actually *all* references need to check the
global list.


Instead of tainting the name, we can taint the value. This makes more sense
from a use perspective and is simpler to implement (just an extra boolean
in the value object representing the custom property).

In more detail, when a custom property is defined inside an @keyframes
rule, or animated using a transition rule, the value assigned to that
property is tainted. When a tainted custom property value is incorporated
into another value, the new value also becomes tainted.

If a tainted value is incorporated into an animation or transition
property, then the value should be considered as the empty string for the
purpose of determining the value of that property.





Received on Thursday, 18 February 2016 22:18:31 UTC