Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

[David Baron]

Contact emails

dba...@chromium.org

Explainer

None

Specification

https://www.w3.org/TR/css-values-3/#custom-idents

Summary

The CSS keyword 'default' is not allowed within CSS custom identifiers, which are used for many types of user-defined names in CSS (for example, names created by @keyframes rules, counters, @container names, custom layout or paint names). This adds 'default' to the list of names that are reserved from being used in custom identifiers, which already reserve 'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.

Note that some existing CSS features that accept custom identifiers check specifically for 'default' to avoid the risk of worsening the potential compatibility problem in this deprecation. This means that fixing the general code for custom identifiers will fix the remaining cases, though some cases are already fixed.

Blink component

Blink>CSS

Motivation

Keywords that CSS uses (or is likely to use in the future) as values accepted by any CSS property should not be allowed in custom identifiers because many custom identifiers are also values of CSS properties. If they can be custom identifiers, then developers could create content that would be broken by the addition of these keywords as property values either to all CSS properties, or to a particular CSS property that already accepts custom identifiers.

Initial public proposal

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is some compatibility risk if pages are using default as a custom identifier (for example, as the name of an @keyframes rule that is referenced in animation-name). This risk is lessened by the fact that Gecko and WebKit have already shipped this change; thus shipping this deprecation reduces interoperability risk.

Gecko: Shipped/Shipping (https://searchfox.org/mozilla-central/rev/f816e52d85cdaf0be7c9e1d2297f833e9ef53e2e/servo/components/style/values/mod.rs#462)

WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/parser/CSSParserIdioms.h#L77)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

The debuggability matches the debuggability of syntax errors produced for existing invalid values, which include the reserved names 'inherit', 'initial', etc.

Is this feature fully tested by web-platform-tests?

No.

There are tests for some, but not all, of the features that use custom identifiers. I hope to add a few more as part of landing this. An existing test that covers this case is: https://wpt.fyi/results/css/css-properties-values-api/register-property-syntax-parsing.html?label=stable&label=master and an existing test that should be expanded is: https://wpt.fyi/results/css/css-font-loading/fontfaceset-load-css-wide-keywords.html?label=stable&label=master

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=882285

Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/2628 is a use counter that is currently around 0.0086% and increasing.

https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1170371304 has data from a cluster telemetry run showing one site in the 10K set that could be affected.

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096490737860608

This intent message was generated by Chrome Platform Status and then hand edited.

[Yoav Weiss]

Oh my, I wish we pulled the trigger on this 2 years ago.. 

Any ideas what breakage may look like? Any of these sites with open compat issues on Firefox/WebKit? (Or are they serving this content only to Chromium/Chrome?)

https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1170371304 has data from a cluster telemetry run showing one site in the 10K set that could be affected.

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096490737860608

This intent message was generated by Chrome Platform Status and then hand edited.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gf2ifuNT64OM7nHvo0jnXxkbZ4BmAh%2BYw0UUSq_iG%3D_g%40mail.gmail.com.

[David Baron]

As far as what the breakage might look like:  it would look different for the different uses of custom idents in CSS.  The possible cases are the CSS features that (a) use custom idents and (b) are shipping (no flag or a flag with "status: stable") and (c) don't already separately forbid default.  That list is the following:

• CSS animation names (the @keyframes rule and the value of animation-name).  In this case, the breakage would most likely be the absence of a CSS animation that was supposed to happen.  It could also lead to a *different* set of CSS animations running, if one (now broken) CSS declaration of animation or animation-name was previously overriding another (still working) one.
• CSS counter names in the counter-reset, counter-increment, and counter-set properties and the counter() and counters() values of the content property.  This failure would likely lead to incorrect numbering of list-items, footnotes, headings, or something else numbered via CSS.
• The CSS Paint API accepts custom idents as names of the paint functions.  Failure here would lead to a custom paint use not working.
• A property defined with the @property at-rule's syntax descriptor to take a <custom-ident> value would also no longer accept default as a value where the <custom-ident> was used.
• The CSS page property accepts custom idents for named pages.  This could lead to printing on an incorrectly sized or oriented page or with incorrect margins.
• The CSS @counter-style rule's symbol descriptor accepts custom idents in place of strings.  Use of "default" here seems very unlikely in valid usage since it is unlikely that the string "default" is used as a list marker.
• The values of CSS transition-property accept custom-idents as a forward-compatibility mechanism, to avoid having parse errors when current and future CSS properties are mixed.  This means that if a developer attempted to specify a transition on a list of CSS properties that included default, behavior could change, because that list would now be ignored (either leaving no transitions or fallback to another declaration).
• Likewise, the CSS color-scheme property accepts custom-idents as a forward-compatibility mechanism.

As far as the observed sites in w3c/csswg-drafts#7431 -- for a start, I should point out that what led to this intent was a discussion in the CSS Working Group about adding a few *additional* keywords to the list of reserved words here.  This led me to gather compatibility data on both (a) the proposed additions and (b) the default keyword that we still didn't reserve.  So that list has compatibility data both for this change and for other proposed changes still under discussion in the WG.  However, it's probably useful for understanding where custom idents are used in real sites.  I've added some additional data to that issue about the problems that were detected on the 10K sites dataset (for all of default, auto, none, and normal).  That should give a bit more of a sense of where custom idents are used in live CSS, though I suspect the distribution varies for the different keywords based on how they are likely to make sense as names for the different usages.  I think it does, however, confirm my prior expectation that the bulk of problematic usage is likely to be related to CSS animations.  (I'd note that in the data on that issue, there were a number of cases of CSS grid lines called none.  Grid lines are not an issue for this intent because they're one of the cases that already exclude default.)

Most relevant to this intent is the case on http://www.elster.de where default is used (which is the only actual site that I'm aware of this change affecting):  it is a use in the animation-name property.  The relevant chunk of CSS is the following (with newlines added):

body{animation-name:default;animation-duration:1ms;content:'default'}

@media screen and (min-width:20rem),print{body{animation-name:min;content:'min'}}

@media screen and (min-width:30rem),print{body{animation-name:xs;content:'xs'}}

@media screen and (min-width:48rem),print{body{animation-name:small;content:'small'}}

@media screen and (min-width:60rem),print{body{animation-name:content;content:'content'}}

@media screen and (min-width:60rem),print{body{animation-name:medium;content:'medium'}}

@media screen and (min-width:80rem),print{body{animation-name:large;content:'large'}}

@media screen and (min-width:105rem),print{body{animation-name:xl;content:'xl'}}

@media screen and (min-width:120rem),print{body{animation-name:max;content:'max(a, b)'}}

@keyframes default{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes min{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes xs{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes small{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes content{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes medium{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes large{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes xl{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes max{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

This is rather a lot of CSS to apply the clip property to body for the first 1ms of the page's existence.  I'm not sure why it's there, but maybe it's a workaround for something.  In any case, this change would cause this chunk of CSS to no longer do whatever it does (which is likely not very much) for pages whose width is less than 20rem.

elster.de has had a bunch of webcompat issues with Firefox, but none of the ones in that list seem related to this issue.

-David

[David Baron]

On Thu, Jul 7, 2022 at 10:36 AM David Baron <dba...@chromium.org> wrote:

Most relevant to this intent is the case on http://www.elster.de where default is used (which is the only actual site that I'm aware of this change affecting):  it is a use in the animation-name property.  The relevant chunk of CSS is the following (with newlines added):

body{animation-name:default;animation-duration:1ms;content:'default'}

@media screen and (min-width:20rem),print{body{animation-name:min;content:'min'}}

@media screen and (min-width:30rem),print{body{animation-name:xs;content:'xs'}}

@media screen and (min-width:48rem),print{body{animation-name:small;content:'small'}}

@media screen and (min-width:60rem),print{body{animation-name:content;content:'content'}}

@media screen and (min-width:60rem),print{body{animation-name:medium;content:'medium'}}

@media screen and (min-width:80rem),print{body{animation-name:large;content:'large'}}

@media screen and (min-width:105rem),print{body{animation-name:xl;content:'xl'}}

@media screen and (min-width:120rem),print{body{animation-name:max;content:'max(a, b)'}}

@keyframes default{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes min{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes xs{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes small{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes content{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes medium{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes large{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes xl{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

@keyframes max{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

This is rather a lot of CSS to apply the clip property to body for the first 1ms of the page's existence.  I'm not sure why it's there, but maybe it's a workaround for something.  In any case, this change would cause this chunk of CSS to no longer do whatever it does (which is likely not very much) for pages whose width is less than 20rem.

elster.de has had a bunch of webcompat issues with Firefox, but none of the ones in that list seem related to this issue.

And one further point about www.elster.de that I had forgotten about:  the clip property only applies to absolutely positioned elements, which their body element is not.  So whether or not default is valid as a custom-ident, the above CSS should be 18 lines of no-op.

-David

[Yoav Weiss]

LGTM1 given the thorough analysis and my understanding based on it that the use counter is likely to be over-counting actual breakage. Thanks for running it! :)

[Manuel Rego Casasnovas]

LGTM2

> elster.de <http://elster.de> has had
> <https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+elster> a

> bunch of webcompat issues with Firefox, but none of the ones in
> that list seem related to this issue.
>
>

> And one further point about www.elster.de <http://www.elster.de>

> that I had forgotten about:  the clip property only applies to
> absolutely positioned elements, which their body element is not.  So
> whether or not default is valid as a custom-ident, the above CSS
> should be 18 lines of no-op.
>
> -David
>

> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUoDE6%3D8rZoC40022HAavqcEziTjTn8cO4vczWR1yGz3g%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUoDE6%3D8rZoC40022HAavqcEziTjTn8cO4vczWR1yGz3g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01aabf33-c19b-268a-2acb-fa1d7ffda983%40igalia.com.

[Joe Medley]

David,

In which milestone will this be removed?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gf2ifuNT64OM7nHvo0jnXxkbZ4BmAh%2BYw0UUSq_iG%3D_g%40mail.gmail.com.

[David Baron]

On Mon, Jul 11, 2022 at 12:10 PM Joe Medley <jme...@google.com> wrote:

In which milestone will this be removed?

Assuming nothing changes, Chrome 105.  I've updated chromestatus.

On Thu, Jul 7, 2022 at 10:36 AM David Baron <dba...@chromium.org> wrote:

As far as what the breakage might look like:  it would look different for the different uses of custom idents in CSS.  The possible cases are the CSS features that (a) use custom idents and (b) are shipping (no flag or a flag with "status: stable") and (c) don't already separately forbid default.  That list is the following:

• CSS animation names (the @keyframes rule and the value of animation-name).  In this case, the breakage would most likely be the absence of a CSS animation that was supposed to happen.  It could also lead to a *different* set of CSS animations running, if one (now broken) CSS declaration of animation or animation-name was previously overriding another (still working) one.
• CSS counter names in the counter-reset, counter-increment, and counter-set properties and the counter() and counters() values of the content property.  This failure would likely lead to incorrect numbering of list-items, footnotes, headings, or something else numbered via CSS.
• The CSS Paint API accepts custom idents as names of the paint functions.  Failure here would lead to a custom paint use not working.
• A property defined with the @property at-rule's syntax descriptor to take a <custom-ident> value would also no longer accept default as a value where the <custom-ident> was used.
• The CSS page property accepts custom idents for named pages.  This could lead to printing on an incorrectly sized or oriented page or with incorrect margins.
• The CSS @counter-style rule's symbol descriptor accepts custom idents in place of strings.  Use of "default" here seems very unlikely in valid usage since it is unlikely that the string "default" is used as a list marker.
• The values of CSS transition-property accept custom-idents as a forward-compatibility mechanism, to avoid having parse errors when current and future CSS properties are mixed.  This means that if a developer attempted to specify a transition on a list of CSS properties that included default, behavior could change, because that list would now be ignored (either leaving no transitions or fallback to another declaration).
• Likewise, the CSS color-scheme property accepts custom-idents as a forward-compatibility mechanism.

In the process of writing the change, I found that there were some additional cases (that I could remove in the change) that separately forbade default.  This means that, for my 8 item list above, I should actually have removed the fourth and eighth items:

• the @property at-rule's syntax descriptor
  

• the color-scheme property
  

and thus there are only 6 cases where I believe the behavior changes.

-David