[css-will-change] treatment of upper case values
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- PR merge metrics
- PR metrics pending
Description
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?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the will-change specification and the CSS Values 4 custom-ident definition, then compare the Firefox, Chrome, and Safari behavior described in the issue. Determine whether case-insensitive matching and serialization of property names should be specified explicitly; done means the specification wording resolves the observed differences.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- documentation, web-dev
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100