Thanks for clarifying and verifying! :) My LGTM still stands. On Wed, Oct 4, 2023 at 11:48 AM Anders Hartvoll Ruud <[email protected]> wrote:
> > > On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud <[email protected]> > wrote: > >> On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss <[email protected]> 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). >> > > Just to make sure it wasn't *deliberately* omitted for whatever reason, I > checked with Emilio and they do intend to implement (1) and (2) once it's > specified. > > >> >> 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 < >>> [email protected]> wrote: >>> >>>> Contact emails >>>> >>>> [email protected] >>>> >>>> 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 [email protected]. >>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU8%2BZSKg5LApshP_C_oMKqaU17b25RoFNgH1fMaJgQe3w%40mail.gmail.com.
