Intent to Ship: Relaxed CSS Nesting
Anders Hartvoll Ruud
Contact emails
Specification
https://drafts.csswg.org/css-syntax/#consume-block-contents
Summary
Allows nested style rules 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.
Blink component
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:
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. 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 [@chromium.org]).
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 [@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?
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
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.
Yoav Weiss
--
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/CAKFBnUpW7rNg%3DUMe34ERTnaFug2W1FPzmYEypOKqLN1Kk1OE2Q%40mail.gmail.com.
Anders Hartvoll Ruud
LGTM1Thanks 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.
Anders Hartvoll Ruud
On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss <yoav...@chromium.org> wrote:LGTM1Thanks 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).
Yoav Weiss
Anders Hartvoll Ruud
Manuel Rego Casasnovas
On 04/10/2023 11:49, Yoav Weiss wrote:
> Thanks for clarifying and verifying! :) My LGTM still stands.
>
> On Wed, Oct 4, 2023 at 11:48 AM Anders Hartvoll Ruud
> <and...@chromium.org <mailto:and...@chromium.org>> wrote:
>
>
>
> On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud
> <and...@chromium.org <mailto:and...@chromium.org>> wrote:
>
> On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss
> <yoav...@chromium.org <mailto:yoav...@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).
>
>
> 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
> On Mon, Oct 2, 2023 at 1:30 PM Anders Hartvoll Ruud
> <and...@chromium.org <mailto:and...@chromium.org>> wrote:
>
>
> Contact emails
>
>
>
> Specification
>
> https://drafts.csswg.org/css-syntax/#consume-block-contents <https://drafts.csswg.org/css-syntax/#consume-block-contents>
>
> Summary
>
> Allows nested style rules
>
> p {
>
> span { color: green; }
>
> }
>
>
> <p>
>
> <span>I am green</span>
>
> </p>
>
>
> “escaped” using :is()or similar, due to restrictions in
> giving the parser the ability to restart
>
>
> 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:
>
>
> 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
> intent changes whenit becomes invalid. With this
> parse-timeinstead of at computed-value time
>
> 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
>
>
> Gecko: Shipped/Shipping
> (https://www.mozilla.org/en-US/firefox/117.0/releasenotes <https://www.mozilla.org/en-US/firefox/117.0/releasenotes>)
>
>
> WebKit: In development
> (https://github.com/WebKit/WebKit/pull/17189
> <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
> 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
> “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 beforeshipping.
>
>
>
> https://github.com/w3c/csswg-drafts/issues/9317
> 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
>
>
> There are no anticipated spec changes aftershipping.
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5070369895743488
> <https://chromestatus.com/feature/5070369895743488>
>
>
> This intent message was generated by Chrome Platform
>
> --
> 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
> --
> 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
Chris Harrelson
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/7a09dcfd-d6e4-423a-882e-c5e365de3920%40igalia.com.