On Mon, Jul 11, 2022 at 12:10 PM Joe Medley <jmed...@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 > 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/CAG0MU3iLTasff6SMH2mLgD0N3_89KAhpexO5GsUnGkEdM%2Bk2EA%40mail.gmail.com.
