w3c / w3c/csswg-drafts

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

Open
#3,155 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

css-will-change-1
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.