To match the terminology for the correct item in the list in css-transforms-1, this should probably refer to the "matching transition behavior".

It might be simpler to leave out the "and flip at 50% progress" as this is already defined in web-animations-1. The important part is whether they are transitionable.

If you look at the definition from css-transitions-1:

When comparing the before-change style and after-change style for a given property, the property values are transitionable if they have an animation type that is neither not animatable nor discrete.

We could update this to something like:

When comparing the before-change style and after-change style for a given property, the property values are transitionable if:

• They have an animation type that is neither not animatable nor discrete, or
• The transition-behavior is allow-discrete and they have an animation type that is discrete.

Thanks rob! I replaced this paragraph with your text

I think it's probably best to put the <<transition-behavior-value>> last; the order does affect the order of serialization that the spec requires.

We might want to leave the normal value out of the shorthand - it is the initial value so unnecessary to be specified, and it would prevents its specification in other longhands in the future.

I think leaving normal out of the shorthand is an interesting idea -- but I also think it's not something the WG has done before for any shorthand, so if we think it's worth doing, I think we should bring it up explicitly to the WG to see if other folks have feedback on the idea.

I realize that transition-property takes <custom-ident> values, which means that the spec should probably also have wording excluding the two new keywords from that <custom-ident> as described in https://drafts.csswg.org/css-values-4/#identifier-value , although that change does have (low, I think) compatibility risk.

Or, alternatively, we could choose not to follow that advice and exclude the keywords, in which case we probably do want to leave this in the first position.

I think it's probably best to put the <> last; the order does affect the order of serialization that the spec requires.

So instead of doing transition: allow-discrete display 2s it should be transition: display 2s allow-discrete? Now that the value is called "allow-discrete" I'm more ok with this. When it was just "discrete" or "animatable" I felt more strongly that it should come first. What do you think rob?

the spec should probably also have wording excluding the two new keywords from that <custom-ident>

If we put the keyword at the end, then this wouldn't be needed right?

I don't think the ordering is relevant. This affects the parsing rules -- and effectively without that exclusion the spec would need prose rules for how to distinguish the values, given that https://drafts.csswg.org/css-values-4/#component-combinators explicitly says that the ordering around || does not matter. (This implies, I think, that it doesn't imply any rule about breaking ties during parsing when more than one option of an || matches. Though maybe that implication wasn't intended. But I think it does imply that it's a specification error if more than one option around an || matches and the spec doesn't say how to resolve the conflict.)

given that https://drafts.csswg.org/css-values-4/#component-combinators explicitly says that the ordering around || does not matter

Oh wow, so transition: 2s color works the same as transition: color 2s!? It looks like this is true after I tried a basic test in chrome.

I moved it to the end of the list