[css-transitions] clarify that the all keyword used in transition-property applies to custom properties

[graouts]

The all keyword used in the transition-property property is defined as such:

the keyword all […] indicates that all properties are to be transitioned.

I think it would help to explicitly call out that all properties includes custom properties. As of this writing, Chrome does not transition registered custom properties when transition-property: all is used, and Safari does not either although WebKit/WebKit#10142 will correct this.

I think it would be useful to clarify as well to clearly distinguish with the all property which specifically calls out that it excludes custom properties:

The all property is a shorthand that resets all CSS properties except direction and unicode-bidi. It only accepts the CSS-wide keywords. It does not reset custom properties [css-variables-1].

Cc @birtles @flackr

[tabatkins]

I'm not sure it's supposed to? The all keyword was originally bespoke, predating both the 'all' property and custom properties, but when we added 'all' it was nice and convenient to have the all keyword switch to just being a standard property name. And 'all' doesn't shorthand custom properties, so the all keyword won't animate them.

The intention for a long time has been that we would have a '--' property that was a shorthand for all custom properties, identical to 'all', so you could animate all custom properties with transition-property: --;.

That said, there's probably nothing particularly wrong with having the all keyword continue to be bespoke and cause literally all properties to transition. It's just slightly inconsistent with the intended model.

[graouts]

I'm in support of making the all keyword apply to literally all animatable properties. Not doing so is a knock against using custom properties as "real" properties which I find, as an author, @property promotes.

While I have this preference, it's a lot more important to have something clearly spec'd either way.

[tabatkins]

Not doing so is a knock against using custom properties as "real" properties which I find, as an author, @Property promotes.

It's not at all a knock or a judgement, it's a simple application of the rule for shorthand properties. 'all' is not a shorthand for custom props.

[graouts]

Understood, but the all keyword is not the all shorthand property. I understand the historical reasons behind this as you've explained them (it was new information to me), but this distinction should be leveraged here to what I perceive to be the benefit of authors to have the same default behavior for transition: 1s with a custom property as they would with a user-agent-provided property.

[Loirooriol]

I think all should not be treated specially, it should be treated as any other shorthand. See #8024.
We can cover custom properties with --, or add some keyword that doesn't conflict with any property (e.g. everything) to cover all properties (normal and custom).

[flackr]

Note that all will not include discrete properties per our resolution on #4441 - to ensure backwards compat when enabling transitions on discrete properties we have to limit all to interpolable properties.

We were considering a new keyword that would include all discrete properties too.

[Loirooriol]

I don't think it's observable whether all includes discrete properties or not, since they won't be transitionable anyways:

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.

The difference is that, if all covers custom properties, then registered custom properties may not be discrete and then transition. As said in #8024, this is not happening in Blink, which makes sense since custom properties are not longhands of the all shorthand.

Edit: nevermind, the resolution was to also allow transitions of discrete properties.