[css-will-change] treatment of upper case values

[ewilligers]

How should an upper case will-change value like "TRANSFORM" be serialized in specified and computed values? Should it have the same effect as a lower case value?

Firefox:
Values like "TRANSFORM" are serialized with their case preserved in specified and computed values.
Case is ignored when matching against property names, e.g. "TRANSFORM" creates a containing block, just like "transform".
Values that are not a case-insensitive match for a property name are still preserved in specified and computed values.

Chrome:
Values like "TRANSFORM" are serialized in lower case in specified and computed values.
Case is ignored when matching against property names, e.g. "TRANSFORM" creates a containing block, just like "transform".
Values that are not a case-insensitive match for a property name are rejected, i.e. specified value serializes as empty string and computed value is "auto".

Safari:
Values like "TRANSFORM" are serialized in lower case in specified and computed values.
Values that are not a case-insensitive match for a property name have their case preserved in the specified value serialization, but the computed value is "auto".

Edge:
The will-change property is not supported.

The <custom-ident> spec mentions

Such identifiers are fully case-sensitive (meaning they’re compared by codepoint), even in the ASCII range (e.g. example and EXAMPLE are two different, unrelated user-defined identifiers).

The will-change spec mentions

Indicates that the author expects to animate or change the property with the given name on the element in the near future.

Should will-change explicitly mention a case-insensitive match between the custom-ident and propery name?

[heycam]

I think the future-proofing intentions of <custom-ident> mean we shouldn't drop the property altogether like Chrome does. I don't have a strong opinion on the case in the serialization, but there's a very slightly lower risk of compat problems when introducing new properties if we preserve the case and don't drop values that aren't names of properties.

Case sensitivity of the comparison should be mentioned.

Whatever behavior is decided on we should do the same for transition-property.

[tabatkins]

Should will-change explicitly mention a case-insensitive match between the custom-ident and propery name?

Yes, it should.

I think the future-proofing intentions of mean we shouldn't drop the property altogether like Chrome does. I don't have a strong opinion on the case in the serialization, but there's a very slightly lower risk of compat problems when introducing new properties if we preserve the case and don't drop values that aren't names of properties.

Agreed; we should keep the casing for future-proofing reasons (and just general alignment with the treatment of <custom-ident> elsewhere).

Values that are not a case-insensitive match for a property name are rejected, i.e. specified value serializes as empty string and computed value is "auto".

This violates the spec and is a bug in Chrome. The only restriction we place on the <custom-ident> is that it can't be a handful of keywords; other than that it accepts all <custom-ident> values.

[tabatkins]

I specified that matching it against property names is case-insensitive, and added a note about unknown names. Haven't yet specified anything about serialization.

[ewilligers]

In all 4 main browser engines, transition-property values like "TRANSFORM" are serialized in lower case in specified and computed values, while transition-property values like "UPPER" have their case preserved in specified and computed values.

[tabatkins]

I'm not super dedicated to fighting this, but that sort of dependent normalization is a forward-compatibility risk; certain values can serialize differently depending on whether the browser recognizes it as a known property or not. I'd prefer if we always left it unchanged, in both of those places. (And in every other place we use a <custom-ident>.)

(I presume the normalization is so that the browser can trivially check for it later in a map of property names?)