Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Chris Harrelson]

LGTM3

On Wed, Oct 4, 2023 at 3:54 AM Manuel Rego Casasnovas 
wrote:

> LGTM2
>
> 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
> > mailto:andr...@chromium.org>> wrote:
> >
> >
> >
> > On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud
> > mailto:andr...@chromium.org>> wrote:
> >
> > On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss
> > mailto: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).
> >
> >
> > 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
> > mailto:andr...@chromium.org>> wrote:
> >
> >
> > Contact emails
> >
> > andr...@chromium.org 
> >
> >
> > Specification
> >
> >
> https://drafts.csswg.org/css-syntax/#consume-block-contents <
> 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; }
> >
> > }
> >
> >
> > 
> >
> >I am green
> >
> > 
> >
> >
> > Before this change, the inner spanselector 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 whenit becomes invalid. With this
> > intent, e.g. color: var(--x) {};becomes invalid
> > parse-timeinstead of at computed-value time
> > <
> https://drafts.csswg.org/css-variables/#invalid-at-computed-value-time>.
> This isan 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 ]).
> 

Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Manuel Rego Casasnovas]

LGTM2

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 
mailto:andr...@chromium.org>> wrote:




On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud
mailto:andr...@chromium.org>> wrote:

On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss
mailto: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).


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
mailto:andr...@chromium.org>> wrote:


Contact emails

andr...@chromium.org 


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; }

}




   I am green




Before this change, the inner spanselector 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

Blink>CSS




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 whenit becomes invalid. With this
intent, e.g. color: var(--x) {};becomes invalid
parse-timeinstead of at computed-value time

. This isan 
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
 ]).

 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
  

Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Yoav Weiss]

Thanks for clarifying and verifying! :) My LGTM still stands.

On Wed, Oct 4, 2023 at 11:48 AM Anders Hartvoll Ruud 
wrote:

>
>
> On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud 
> wrote:
>
>> On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss  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 <
>>> andr...@chromium.org> wrote:
>>>
 Contact emails

 andr...@chromium.org

 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; }

 }

 

   I am green

 

 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

 Blink>CSS
 

 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

 .
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]).
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

 
[@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 platform

Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Anders Hartvoll Ruud]

On Tue, Oct 3, 2023 at 8:46 PM Anders Hartvoll Ruud 
wrote:

> On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss  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 
>> wrote:
>>
>>> Contact emails
>>>
>>> andr...@chromium.org
>>>
>>> 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; }
>>>
>>> }
>>>
>>> 
>>>
>>>   I am green
>>>
>>> 
>>>
>>> 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
>>>
>>> Blink>CSS
>>> 
>>>
>>> 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
>>>.
>>>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]).
>>>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
>>>
>>> 
>>>[@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 

Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Anders Hartvoll Ruud]

On Tue, Oct 3, 2023 at 3:14 PM Yoav Weiss  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 
> wrote:
>
>> Contact emails
>>
>> andr...@chromium.org
>>
>> 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; }
>>
>> }
>>
>> 
>>
>>   I am green
>>
>> 
>>
>> 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
>>
>> Blink>CSS
>> 
>>
>> 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
>>.
>>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]).
>>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
>>
>> 
>>[@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
>> ge

Re: [blink-dev] Intent to Ship: Relaxed CSS Nesting

[Yoav Weiss]

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.

On Mon, Oct 2, 2023 at 1:30 PM Anders Hartvoll Ruud 
wrote:

> Contact emails
>
> andr...@chromium.org
>
> 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; }
>
> }
>
> 
>
>   I am green
>
> 
>
> 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
>
> Blink>CSS
> 
>
> 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
>.
>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]).
>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
>
> 
>[@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
>
> 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/featu

[blink-dev] Intent to Ship: Relaxed CSS Nesting

[Anders Hartvoll Ruud]

Contact emails

andr...@chromium.org

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; }

}



  I am green



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

Blink>CSS


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
   .
   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]).
   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
   

   [@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

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
.

-- 
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.