[css-contain] `contain` may not want to be animatable.

[emilio]

I can't think of a use case for it, and sounds like it may make optimizing it harder? Though I don't have a sense of this, maybe @mrego does.

cc @birtles, which noticed this.

[tabatkins]

While animating it would negate much of the performance benefit, there's nothing about it that makes it bad to animate (unlike 'display', 'animation-*', etc). Considering how useful it is to animate various other properties without actual animation behavior (like, say, border-style from "none" to "solid"), I'm loathe to restrict properties that don't cause actual logical issues with animation.

[tabatkins]

Note: I'm not strongly against it, I'm just holding the general position of "let people shoot themselves in the foot unless it actually causes problems".

[birtles]

My concern is that at an implementation point of view it's slightly more complex to depend on the animated value of a property, than it's computed value.

We'll need to ensure that will-change: contain generates a stacking context too (since we don't want animations generating stacking contexts mid-way through as it looks horrible, causes jank, and prevents sending them to the compositor in advance).

[frivoal]

I'm confused. It already says Animation type: discrete. Is there such a thing as Animation type: none? Otherwise, what are you asking about?

Reading https://drafts.csswg.org/css-transitions/#animatable-types:

Some property types can be interpolated, which means they can animate smoothly from one value to another. Other property types cannot, and thus animate only in a single step from one value to the other.

That does not suggest a difference between discrete and none.

[birtles]

Yes, there is such a thing as Animation type: not animatable. For example see the animation-duration property. Web animations also defines the not animatable concept.

[frivoal]

I continue to be confused. Some specs use Animatable as an entry in the propdef table. Some use Animation type. I had been under the impression that Animatable: no was the old way of phrasing Animation Type: discrete.

Issue 1 in the transition spec supports this:

It no longer makes sense for this line to be called "Animatable". It should probably be renamed to "Interpolation", and the "no" value renamed to "discrete" or "in steps". See mailing list thread: message 1, message 2

[frivoal]

So If the web Animation spec is right that some properties can be non animatable (as a separate concept from discrete interpolation), this needs to be clarified in the transitions and animations spec, including a definition of what happens when you transition over a non animatable property, then we need to review all the specs that use Animatable: none to decide if they mean Animation Type: discrete or Animation Type: none.

Or, we decide that there is no distinction, in which case Web Animations needs to be fixed. (and we still need to update all instances of Animatable: * into Animation Type: *

[birtles]

There a summary of the status quo here: #2736 (comment)

Basically, I need to edit V&U before I can fix the other specs but every time I've tried I've got stuck working out how to refactor V&U.