Re: [blink-dev] Intent to Ship: Stable Bare Declarations (@nest)

2024-04-30 Thread PhistucK 
So we are back to the worst possible outcome? :(

☆*PhistucK*


On Sat, Apr 27, 2024 at 8:31 AM Anders Hartvoll Ruud 
wrote:

> Oops, I intended to send that e-mail to the list, must have hit "Reply"
> instead of "Reply All".
>
> On Fri, Apr 26, 2024 at 10:45 AM Anders Hartvoll Ruud <
> andr...@chromium.org> wrote:
>
>>
>>
>> On Fri, Apr 26, 2024 at 4:09 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 25, 2024 at 6:14 PM Anders Hartvoll Ruud <
>>> andr...@chromium.org> wrote:
>>>
 Contact emails

 andr...@chromium.org

 Specification

 https://drafts.csswg.org/css-nesting-1/#nest-rule

 Summary

 CSS Nesting initially shipped with an interesting quirk that would
 cause bare declarations that come after a nested rule to “shift”, for
 example:

 .foo {

   width: 100px;

   height: 100px;

   @media screen {

 background-color: red;

   }

   background-color: green;

 }

 You would think that the background-color of  would be
 green here, but no, that declaration is shifted up to the main (leading)
 block of declarations during parsing:

 .foo {

   width: 100px;

   height: 100px;

   background-color: green; /* I’m here now */

   @media screen {

 background-color: red;

   }

 }

 This was at the time done intentionally for a mix of CSSOM and
 historical reasons, and all implementations of CSS Nesting currently agree
 on this behavior. However, it turns out this shifting behavior isn’t what
 authors expect (WebKit blog post
 ),
 and the CSSWG now consider the decision a mistake. In October 2023, the
 CSSWG resolved
 
 to not do the shifting behavior anymore, without explaining how to
 solve the problems that would arise from that (Issue 9492
 ).

 One promising approach, @nest (proposed by Tab
 ),
 became the basis for my web compat investigation (Doc
 ,
 @chromium.org), and recently I shared some good news
 
 from the use-counters with the CSSWG. This restarted the discussion, and
 while the CSSWG did agree
 
 on the underlying @nest approach, it also basically split people into two
 camps:


1.

@nest should be a web-exposed construct. (Currently specified, per Issue
8738

 
).
2.

@nest should as much as possible be an implementation detail,
unobservable to the author. (Issue 10234
).


 The apparent positions so far are that Firefox and Chrome support (1),
 and Safari (+ other prominent CSSWG members) support (2). At the time of
 writing, this is where the discussion is now.

 The CSSWG agrees that addressing the “bare declaration shift” is the
 most important thing, and also quite urgent, since we don’t know how long
 the window for making a change here is going to stay open. The
 expectation
 
 of the CSSWG seems to be that browsers first ship @nest as it’s currently
 specified (1), and then we possibly move towards (2) later. I find this
 move problematic, since moving to (2) would break the API again, and even
 if we reasonably believe it will break the API in a much less severe way,
 it may be hard to actually prove this.

 Despite this, I have agreed to try to ship @nest, on the condition that
 we have clear signals from Firefox and Safari that they’ll do the same. I
 don’t yet have those signals, but I’m sending the intent “early” anyway, to
 give this issue some visibility.

>>>
>>> I saw this morning that WebKit now opposes this proposal
>>> . Since you
>>> phrased this as a condition, should we consider the Intent withdrawn, as
>>> the condition is not met?
>>>
>>
>> Yes, consider it withdrawn. I am happy with this outcome for now.
>>
>>
>>>
 Blink component

 Blink>CSS

Re: [blink-dev] Intent to Ship: Stable Bare Declarations (@nest)

2024-04-27 Thread Anders Hartvoll Ruud 
Oops, I intended to send that e-mail to the list, must have hit "Reply"
instead of "Reply All".

On Fri, Apr 26, 2024 at 10:45 AM Anders Hartvoll Ruud 
wrote:

>
>
> On Fri, Apr 26, 2024 at 4:09 AM Domenic Denicola 
> wrote:
>
>>
>>
>> On Thu, Apr 25, 2024 at 6:14 PM Anders Hartvoll Ruud <
>> andr...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> andr...@chromium.org
>>>
>>> Specification
>>>
>>> https://drafts.csswg.org/css-nesting-1/#nest-rule
>>>
>>> Summary
>>>
>>> CSS Nesting initially shipped with an interesting quirk that would cause
>>> bare declarations that come after a nested rule to “shift”, for example:
>>>
>>> .foo {
>>>
>>>   width: 100px;
>>>
>>>   height: 100px;
>>>
>>>   @media screen {
>>>
>>> background-color: red;
>>>
>>>   }
>>>
>>>   background-color: green;
>>>
>>> }
>>>
>>> You would think that the background-color of  would be
>>> green here, but no, that declaration is shifted up to the main (leading)
>>> block of declarations during parsing:
>>>
>>> .foo {
>>>
>>>   width: 100px;
>>>
>>>   height: 100px;
>>>
>>>   background-color: green; /* I’m here now */
>>>
>>>   @media screen {
>>>
>>> background-color: red;
>>>
>>>   }
>>>
>>> }
>>>
>>> This was at the time done intentionally for a mix of CSSOM and
>>> historical reasons, and all implementations of CSS Nesting currently agree
>>> on this behavior. However, it turns out this shifting behavior isn’t what
>>> authors expect (WebKit blog post
>>> ),
>>> and the CSSWG now consider the decision a mistake. In October 2023, the
>>> CSSWG resolved
>>> 
>>> to not do the shifting behavior anymore, without explaining how to
>>> solve the problems that would arise from that (Issue 9492
>>> ).
>>>
>>> One promising approach, @nest (proposed by Tab
>>> ),
>>> became the basis for my web compat investigation (Doc
>>> ,
>>> @chromium.org), and recently I shared some good news
>>> 
>>> from the use-counters with the CSSWG. This restarted the discussion, and
>>> while the CSSWG did agree
>>> 
>>> on the underlying @nest approach, it also basically split people into two
>>> camps:
>>>
>>>
>>>1.
>>>
>>>@nest should be a web-exposed construct. (Currently specified, per Issue
>>>8738
>>>
>>>).
>>>2.
>>>
>>>@nest should as much as possible be an implementation detail,
>>>unobservable to the author. (Issue 10234
>>>).
>>>
>>>
>>> The apparent positions so far are that Firefox and Chrome support (1),
>>> and Safari (+ other prominent CSSWG members) support (2). At the time of
>>> writing, this is where the discussion is now.
>>>
>>> The CSSWG agrees that addressing the “bare declaration shift” is the
>>> most important thing, and also quite urgent, since we don’t know how long
>>> the window for making a change here is going to stay open. The
>>> expectation
>>> 
>>> of the CSSWG seems to be that browsers first ship @nest as it’s currently
>>> specified (1), and then we possibly move towards (2) later. I find this
>>> move problematic, since moving to (2) would break the API again, and even
>>> if we reasonably believe it will break the API in a much less severe way,
>>> it may be hard to actually prove this.
>>>
>>> Despite this, I have agreed to try to ship @nest, on the condition that
>>> we have clear signals from Firefox and Safari that they’ll do the same. I
>>> don’t yet have those signals, but I’m sending the intent “early” anyway, to
>>> give this issue some visibility.
>>>
>>
>> I saw this morning that WebKit now opposes this proposal
>> . Since you
>> phrased this as a condition, should we consider the Intent withdrawn, as
>> the condition is not met?
>>
>
> Yes, consider it withdrawn. I am happy with this outcome for now.
>
>
>>
>>> Blink component
>>>
>>> Blink>CSS
>>> 
>>>
>>> TAG review
>>>
>>> None
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> This intent is a breaking change, with two main points of breakage:
>>>
>>>
>>>-
>>>
>>>Keeping the bare declarations in place can affect the winner of the
>>>cascade (the example in the

Re: [blink-dev] Intent to Ship: Stable Bare Declarations (@nest)

2024-04-25 Thread Mike Taylor 

On 4/25/24 7:09 PM, Domenic Denicola wrote:

On Thu, Apr 25, 2024 at 6:14 PM Anders Hartvoll Ruud 
 wrote:



Contact emails

andr...@chromium.org


Specification

https://drafts.csswg.org/css-nesting-1/#nest-rule



Summary


CSS Nesting initially shipped with an interesting quirk that would
cause bare declarations that come after a nested rule to “shift”,
for example:


.foo {

  width: 100px;

  height: 100px;

  @media screen {

background-color: red;

  }

  background-color: green;

}


You would think that the background-colorof would
be green here, but no, that declaration is shifted up to the main
(leading) block of declarations during parsing:


.foo {

  width: 100px;

  height: 100px;

  background-color: green; /* I’m here now */

  @media screen {

background-color: red;

  }

}


This was at the time done intentionally for a mix of CSSOM and
historical reasons, and all implementations of CSS Nesting
currently agree on this behavior. However, it turns out this
shifting behavior isn’t what authors expect (WebKit blog post

),
and the CSSWG now consider the decision a mistake. In October
2023, the CSSWG resolved
to
not do the shifting behavior anymore, without explaining howto
solve the problems that would arise from that (Issue 9492
).


One promising approach, @nest (proposed by Tab

),
became the basis for my web compat investigation (Doc

,
@chromium.org ), and recently I shared some
good news

from
the use-counters with the CSSWG. This restarted the discussion,
and while the CSSWG did agree
on
the underlying @nest approach, it also basically split people into
two camps:


1.

@nest should be a web-exposed construct. (Currently specified,
per Issue 8738

).


2.

@nest should as much as possible be an implementation detail,
unobservable to the author. (Issue 10234
).


The apparentpositions so far are that Firefox and Chrome support
(1), and Safari (+ other prominent CSSWG members) support (2). At
the time of writing, this is where the discussion is now.


The CSSWG agrees that addressing the “bare declaration shift” is
the most important thing, and also quite urgent, since we don’t
know how long the window for making a change here is going to stay
open. The expectation
of
the CSSWG seems to be that browsers first ship @nest as it’s
currently specified (1), and then we possibly move towards (2)
later. I find this move problematic, since moving to (2) would
break the API again, and even if we reasonably believe it will
break the API in a much less severe way, it may be hard to
actually prove this.


Despite this, I have agreed to try to ship @nest, on the condition
that we have clear signals from Firefox and Safari that they’ll do
the same. I don’t yet have those signals, but I’m sending the
intent “early” anyway, to give this issue some visibility.


I saw this morning that WebKit now opposes this proposal 
. Since you 
phrased this as a condition, should we consider the Intent withdrawn, 
as the condition is not met?


+1 to this, but can you also explain why you think it's a good idea to 
ship, despite finding the proposal problematic?




Anticipated spec changes


Yes, a major one, as explained in the introduction: Issue 10234
.


I am attempting to ship despite this issue, since that’s what the
CSSWG wants.


Note also: Recently in the above issue, we are now considering a
third approach: renaming @nest to something more generic, with the
intent to maybe make it more useful in the future, and therefore
making its web-exposed presence less annoying. This shows some
promise in terms of unifying camps (1) and (2), so

Re: [blink-dev] Intent to Ship: Stable Bare Declarations (@nest)

2024-04-25 Thread Domenic Denicola 
On Thu, Apr 25, 2024 at 6:14 PM Anders Hartvoll Ruud 
wrote:

> Contact emails
>
> andr...@chromium.org
>
> Specification
>
> https://drafts.csswg.org/css-nesting-1/#nest-rule
>
> Summary
>
> CSS Nesting initially shipped with an interesting quirk that would cause
> bare declarations that come after a nested rule to “shift”, for example:
>
> .foo {
>
>   width: 100px;
>
>   height: 100px;
>
>   @media screen {
>
> background-color: red;
>
>   }
>
>   background-color: green;
>
> }
>
> You would think that the background-color of  would be
> green here, but no, that declaration is shifted up to the main (leading)
> block of declarations during parsing:
>
> .foo {
>
>   width: 100px;
>
>   height: 100px;
>
>   background-color: green; /* I’m here now */
>
>   @media screen {
>
> background-color: red;
>
>   }
>
> }
>
> This was at the time done intentionally for a mix of CSSOM and historical
> reasons, and all implementations of CSS Nesting currently agree on this
> behavior. However, it turns out this shifting behavior isn’t what authors
> expect (WebKit blog post
> ),
> and the CSSWG now consider the decision a mistake. In October 2023, the
> CSSWG resolved
> 
> to not do the shifting behavior anymore, without explaining how to solve
> the problems that would arise from that (Issue 9492
> ).
>
> One promising approach, @nest (proposed by Tab
> ),
> became the basis for my web compat investigation (Doc
> ,
> @chromium.org), and recently I shared some good news
> 
> from the use-counters with the CSSWG. This restarted the discussion, and
> while the CSSWG did agree
> 
> on the underlying @nest approach, it also basically split people into two
> camps:
>
>
>1.
>
>@nest should be a web-exposed construct. (Currently specified, per Issue
>8738
>
>).
>2.
>
>@nest should as much as possible be an implementation detail,
>unobservable to the author. (Issue 10234
>).
>
>
> The apparent positions so far are that Firefox and Chrome support (1),
> and Safari (+ other prominent CSSWG members) support (2). At the time of
> writing, this is where the discussion is now.
>
> The CSSWG agrees that addressing the “bare declaration shift” is the most
> important thing, and also quite urgent, since we don’t know how long the
> window for making a change here is going to stay open. The expectation
> 
> of the CSSWG seems to be that browsers first ship @nest as it’s currently
> specified (1), and then we possibly move towards (2) later. I find this
> move problematic, since moving to (2) would break the API again, and even
> if we reasonably believe it will break the API in a much less severe way,
> it may be hard to actually prove this.
>
> Despite this, I have agreed to try to ship @nest, on the condition that we
> have clear signals from Firefox and Safari that they’ll do the same. I
> don’t yet have those signals, but I’m sending the intent “early” anyway, to
> give this issue some visibility.
>

I saw this morning that WebKit now opposes this proposal
. Since you
phrased this as a condition, should we consider the Intent withdrawn, as
the condition is not met?


>
> Blink component
>
> Blink>CSS
> 
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> Risks
>
> This intent is a breaking change, with two main points of breakage:
>
>
>-
>
>Keeping the bare declarations in place can affect the winner of the
>cascade (the example in the introduction). This is covered by
>CSSBareDeclarationShift
>
>(0.00027%).
>-
>
>Additionally, @nest will have different specificity behavior for
>nested group rules, and this can also affect the winner of the cascade.
>This is covered by CSSNestedGroupRuleSpecificity
>
>(0.00017%).
>
>
> Interoperability and Compatibility
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/1013) - Emilio
> seems positive, but the