[css-variables] When does substitution occur, before or after animation interopolation?

[gregwhitworth]

I think the spec could be a little bit more clear on when substitution actually occurs for custom properties. We know that they happen during computed value time, but this doesn't get into the minutia of whether or not this occurs before the animation interpolation or after.

If you take the following example, what should happen:
http://jsbin.com/busapezohu/1/edit?html,css,output

Chrome: No background is painted for either div
FF: Second div background is transitioned

Currently the spec states the following:

Notably, they can even be transitioned or animated, but since the UA has no way to interpret their contents, they always use the "flips at 50%" behavior that is used for any other pair of values that can’t be intelligently interpolated. However, any custom property used in a @Keyframes rule becomes animation-tainted, which affects how it is treated when referred to via the var() function in an animation property.

This seems to state that they should work, but that it may not be possible to correctly interpolate a custom property (as seen in the test animation since it's merely an ident at that point). So I would suggest that what Firefox is doing is the correct outcome, that you do substitution first and then any animation interpolation once we know the value and the property it is applied to is blue we can correctly interpolate to that of blue (as seen in the regular testcase).

This may even want to be taken over to the cascade specification where we get more specific about when certain things happen during various stages, in this case Computed Value time.

cc: @shans as this is what I was pinging you about :)

[gregwhitworth]

@tabatkins @shans

I've looked at the Houdini minutes and there was a breakout session regarding this but I can't seem to find minutes. At any rate, basically I'm trying to understand what the preferred expectation is regarding the following code:

div {
  --foo: green;
  background: var(--foo);
  animation: test infinite 1s;
  width: 100px;
  height: 100px;
}

@keyframes test {
  from {
    --foo: blue;
  }
  to {
    --foo: yellow;
  }
}

Should the div be:

• green (what FF/Chrome currently does)
• blue

[jyc]

Hi @gregwhitworth,

I agree the first & third divs should flip at 50% between red and blue, from animation: test 1s infinite on the declaration block for div. As you quoted, 'Notably, they can even be transitioned or animated, but since the UA has no way to interpret their contents, they always use the "flips at 50%" behavior that is used for any other pair of values that can’t be intelligently interpolated'. It looks like this behavior is currently not implemented by Firefox or Chrome, however.

With the patches to implement Properties & Values on Firefox, we do get the 50% flipping behavior, as required by the Properties & Values spec.

Firefox's behavior looks correct for the second div. The .regular declaration block is more specific and takes precedence, so we use the regular animation. In the from keyframe, we take the value from .regular (red), and in to we substitute the --foo declaration there in background. The result is that we have background: red in the first keyframe and background: yellow in the second keyframe, and background is an animatable property & color is interpolable, so we interpolate between red and yellow.

[tabatkins]

@gregwhitworth My expectation is that the div's background flips from blue to yellow. (If that didn't work, the whole "animation-tainted" concept wouldn't be worth much.) The spec does need a little bit more detail there, but the general principle is supposed to be that animations run before we do variable substitution.

[shans]

I agree with Tab - the animation's variable should be used in computation of the style of the div. The fact that --foo is animation-tainted doesn't matter (I think Tab's pointing out we wouldn't need to bother with animation tainting if animation variables couldn't leak into the environment).

I guess what's important is that the animation's variable "wins out" over the one defined in the div rule, but this is just normal - e.g. imagine if you set background directly in the animation instead.

[gregwhitworth]

@shans @tabatkins Thanks, this is what we were expecting and kind of shocked that currently no one implements it this way. Does Chrome plan to address this, I would assume so since you're working on the Houdini Custom Props which was primarily created for extending the animation capabilities that are somewhat limited due to needing to substitute post animation.

[gregwhitworth]

One last comment, I highly recommend adding it the example I provided with the expected outcome and why. While animation may be considered part of the "cascade" in the Cascade spec it is actually done on the computed results of the cascade. I think this example shows implementers what the expected behavior is, and also informs them that substitution should occur after animation which is currently not stated anywhere, at least not in plain language (it may be implied).

[gregwhitworth]

Going to reopen until the spec update is done, assigning to @tabatkins since he's the editor.

[gregwhitworth]

@tabatkins @shans and myself spoke about animating custom properties and how many substitutions you need in order to support use cases the authors would expect to work. I recommend adding the following copy as a note for an example implementation to ensure the spirit of the specification is followed by all implementations (which when we began this implementation no UA supports this, so it would be good to ensure it's in there).

In order to be able to make the use cases work, here is what an example implementation would look like:

1. Apply cascaded values
2. Detect & Construct animations
3. Substitute into keyframes
4. Detect & construct transitions
5. Apply computed values from transitions and animations
6. Substitute into the cascaded values

While this will help solve some of the gaps and interop issues we found while implementing custom properties, I think we should specify these steps normatively in somewhere (possibly the cascading specification) so that we can reference them and better understand the potential use case and perf impacts with future feature discussions (eg: @apply).

[gregwhitworth]

@tabatkins any thoughts on this? And @fantasai any thoughts on normalizing these steps in the cascade spec so in the future when discussing these types of features and people use the terms such as "an at-apply" point or a "substitution" point; we can better reason about them?

[gregwhitworth]

Hey @tabatkins do you want me to do a PR on this?