W3C home > Mailing lists > Public > www-style@w3.org > February 2016

RE: [css-variables] Animation tainting - proposed change

From: Francois Remy <francois.remy.dev@outlook.com>
Date: Fri, 19 Feb 2016 08:50:22 -0800
Message-ID: <DUB408-EAS775153BF2D91E6B71662EFA5A00@phx.gbl>
To: "'Shane Stephens'" <shans@google.com>, "'www-style list'" <www-style@w3.org>
> 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.

The solution looks fine to me. 
This is actually more logical than what we have now, and closer from how tainting works in other contexts.

A similar solution could be used to avoid double animations in cases like:

    x {   --a: 1;   --b: var(--a);   transition: --a 1s, --b 2s   }
    x:hover {   --a: 2   }
    x:active {   --b: 3   }
    // transitioned value have some special tainting that makes value composed from them untransitionable
    // so that the "b" follows "a" in the :hover case and transitions in one second
    // but transitions in two seconds in the :active case

I'm curious to see what other people who implemented this feel like about it.
Received on Friday, 19 February 2016 16:50:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC