On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> LGTM1 > > Thanks for evaluating the compat risk for this. While non-zero, it seems > manageable given Mozilla already shipping this, with Safari likely to > follow, given the landed implementation. > Clarification: Mozilla is shipping the main part of the feature (retrying a failed declaration as a nested style rule), but they are not (yet) shipping the tweaks to css-syntax described as risk (1) and (2). (1) is a recent resolution (~three weeks), so no mystery there. (2) has been part of this all along - I assume it was seen as something that could be done separately (and it is). So in this case "Mozilla: Shipping" should only be interpreted as a positive signal for the overall change, not as a way to manage compat risk. :-) I'll emphasize again though, that in both (1) and (2), we're just changing from one kind of invalid/has-no-effect to a *slightly* different kind of invalid/has-no-effect. > On Mon, Oct 2, 2023 at 1:30 PM Anders Hartvoll Ruud <andr...@chromium.org> > wrote: > >> Contact emails >> >> andr...@chromium.org >> >> Specification >> >> https://drafts.csswg.org/css-syntax/#consume-block-contents >> >> Summary >> >> Allows nested style rules >> <https://drafts.csswg.org/css-nesting-1/#nested-style-rule> to begin >> with an identifier. For example, the following will now be possible: >> >> p { >> >> span { color: green; } >> >> } >> >> <p> >> >> <span>I am green</span> >> >> </p> >> >> Before this change, the inner span selector had to be “escaped” using >> :is() or similar, due to restrictions in css-syntax. These restrictions >> have now been lifted by giving the parser the ability to restart >> <https://drafts.csswg.org/css-syntax/#token-stream-restore-a-mark>. >> >> Blink component >> >> Blink>CSS >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >> >> TAG review >> >> None >> >> TAG review status >> >> Not applicable >> >> Risks >> >> Interoperability and Compatibility >> >> To address some problematic parsing edge cases, the CSSWG has made two >> additional changes to css-syntax that have theoretical web-facing impact. >> These changes will ship in this intent as well: >> >> >> 1. >> >> Braces ({}) are now fundamentally invalid in standard properties, >> unless they span the whole value. No property grammar allows {} in >> any part of the value currently, so this is already invalid, but when >> var() is used in combination with {}, this intent changes when it >> becomes invalid. With this intent, e.g. color: var(--x) {}; becomes >> invalid parse-time instead of at computed-value time >> <https://drafts.csswg.org/css-variables/#invalid-at-computed-value-time>. >> This is an observable difference, but there’s no known reason for >> this to occur in practice outside of mistakes. Nevertheless, I have >> tried to estimate the number of possibly-impacted sites: ~0.0011% (Web >> Compat Analysis: Relaxed Nesting >> >> <https://docs.google.com/document/d/1WxIAXWFy3q9XJrFK8k2J5my71jn8Cvdxq6Z8NAg99Q0/edit#bookmark=id.ufp2erlyto93> >> [@chromium.org]). >> 2. >> >> A style rule prelude (i.e. the selector list) can no longer start >> with --ident:. Again, this is in a sense already “invalid”, since >> HTML elements never start with -- (including custom elements, which must >> start with a letter), so such rules can never match anything. This intent >> makes the situation a parse error instead. Estimated impact: ~0.0007% (Web >> Compat Analysis: Relaxed Nesting >> >> <https://docs.google.com/document/d/1WxIAXWFy3q9XJrFK8k2J5my71jn8Cvdxq6Z8NAg99Q0/edit#bookmark=id.geo17wxm8bwh> >> [@chromium.org]). >> >> >> Gecko: Shipped/Shipping ( >> https://www.mozilla.org/en-US/firefox/117.0/releasenotes) >> >> WebKit: In development (https://github.com/WebKit/WebKit/pull/17189) >> >> 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? >> >> None >> >> >> Debuggability >> >> Nested style rules that start with identifiers appear in the inspector >> like other nested style rules. >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)? >> >> Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes >> >> The tests exist in wpt_internal/css/css-nesting/ident at the time of >> writing, but will be upstreamed when the feature is turned on. >> >> Flag name on chrome://flags >> >> CSSNestingIdent >> >> Finch feature name >> >> I’m not sure what a “Finch feature name” is. There have been no Finch >> trials related to this, but the feature is guarded by the Blink runtime >> flag “CSSNestingIdent” with “base_feature” unset, which automatically >> generates a corresponding base::Feature. >> >> Non-finch justification >> >> None >> >> Requires code in //chrome? >> >> False >> >> Estimated milestones >> >> Shipping on desktop >> >> 120 >> >> Shipping on Android >> >> 120 >> >> Shipping on WebView >> >> 120 >> >> >> >> Anticipated spec changes >> >> These issues need to be resolved and/or edited into the spec before >> shipping. >> >> >> - >> >> https://github.com/w3c/csswg-drafts/issues/9317 >> The behavior that braces are invalid in standard properties (unless >> it’s the whole value) was resolved at TPAC 2023, but css-syntax has not >> been updated yet. >> - >> >> https://github.com/w3c/csswg-drafts/issues/9336 >> This is a tweak to the error recovery of the --ident: case. This >> needs a resolution, and an edit. >> >> >> There are no anticipated spec changes after shipping. >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5070369895743488 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> 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/CAKFBnUpW7rNg%3DUMe34ERTnaFug2W1FPzmYEypOKqLN1Kk1OE2Q%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUpW7rNg%3DUMe34ERTnaFug2W1FPzmYEypOKqLN1Kk1OE2Q%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/CAKFBnUpP1u%2B8PqngKYm%2BB8%3DGSWqvqZbLgPqvSxU2CUk2zApBcw%40mail.gmail.com.
