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 <https://github.com/w3c/csswg-drafts/issues/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 <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. -David On Thu, Jul 7, 2022 at 1:00 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > > > On Wed, Jul 6, 2022 at 9:50 PM David Baron <dba...@chromium.org> wrote: > >> Contact emailsdba...@chromium.org >> >> ExplainerNone >> >> Specificationhttps://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 componentBlink>CSS >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >> >> 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 statusNot 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?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 bughttps://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. >> > > 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 >> <https://chromestatus.com/> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gf2ifuNT64OM7nHvo0jnXxkbZ4BmAh%2BYw0UUSq_iG%3D_g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gn4Uk7qVcSHfT0XUj3eamWqPp5ic3OQ1EGDbMpXS6e6Q%40mail.gmail.com.
