is that it provides full interoperability between contexts: you can take any CSS code you have today, wrap it in a block, add a selector prefix, and now you have "nested" the existing code without having to make any change.

I am confused by this statement.
It says that you do not need to make any change while outlining the changes you need to make.

} {

I don't think any authors will like writing this at the end of a declaration.

• if you want to add one more declaration you need to move } { to the next one.
• if you re-order declarations the block breaks.
• if you copy/paste that line, it will need to be changed before it will be valid in the next context.

In general I also find that typing } { in that order is awkward.
People will get used to it, but it is uncommon today.

I know that writing } { at the end of a declaration is not required but it is placed there to create the visual illusion of nested curly braces.

It falls apart with different formatting :

div {
  color: red;
} {
  input { margin: 1em; }
}

But I think this style is more realistic with how the feature would be used.

is that it provides full interoperability between contexts: you can take any CSS code you have today, wrap it in a block, add a selector prefix, and now you have "nested" the existing code without having to make any change.

I am confused by this statement. It says that you do not need to make any change while outlining the changes you need to make.

I think @argyleink was confused by that statement, too.

Here is an example of HTML/CSS you might find today: (I just took it from the table spec)

<ul class="table">
  <li><b>One</b><i>1</i></li>
  <li><b>Two</b><i>2</i></li>
  <li><b>Three</b><i>3</i></li>
</ul>
<style>
  ul.table { display: table; }
  ul.table > li { display: table-row; }
  ul.table > li > * { display: table-cell; }
</style>

Let's say that you inherit that code, and realise that it's not such a good idea to use the "table" class that way in your entire codebase, and you want to limit to a section of your site that contains the articles from the legacy system.

You can take the CSS code, prepend :where(article.legacy) {} {, indent the entire list of rules, then close the brace with }.

:where(article.legacy) {} {
  ul.table { display: table; }
  ul.table > li { display: table-row; }
  ul.table > li > * { display: table-cell; }
}

Now, with the current option, proposal 3, this is not sufficient. You have to go and find all selectors that were starting with an indent, and fix them.

:where(article.legacy) {
  & ul.table { display: table; }
  & ul.table > li { display: table-row; }
  & ul.table > li > * { display: table-cell; }
}

This is a manual operation that requires O(n) steps for the author. Each selector needs to be inspected, and then prepended with a '&' symbol if needed. This operation is error-prone and takes time, for something which I expect to be a very common refactoring.

Plus, now, if you want to go back to an independant stylesheet (because, say, you moved to web components and isolated the legacy content there), you have to go back and remove all the & symbols since they don't mean anything anymore. If you had used proposal 4 or 5, you would not need to do this.

This is also true if you move from or to @scope statements. This is another very likely scenario, given the features work similarly but have different effects on cascade importance.

I know that writing } { at the end of a declaration is not required but it is placed there to create the visual illusion of nested curly braces (which falls apart with different formatting).

Yeah, that's true. I don't find that other way of writing it that bad, but it does feel less compact. I'd like to note that the examples for the first spec also use artifically-shortened forms though, like &.c { text-transform:uppercase } one-liners. I find it interesting that most spec examples also all contain an empty line to separate the declarations from the rules, where the two braces could go. A smart IDE could unemphasize these two braces with a different (less-contrasting) coloring, and achieve minimal visual difference between the two proposals that way.

I would also like to point out that with autocompletion these days, you hardly ever write a } yourself. They are auto-inserted. The actual workflow when adding nested rules is more likely to be "click after the } and type { then your rules".

You can take the CSS code, prepend :where(article.legacy) {} {, indent the entire list of rules, then close the brace with }.

Thank you for elaborating, I know understand what the statement intended :)

This operation is error-prone and takes time, for something which I expect to be a very common refactoring.

I find it difficult to weight these correctly.
From my perspective this is a very uncommon case.

Much more common to have existing blocks and add something nested inside of it.
The outermost element of a component rarely changes.
Adding or removing extra bits inside seems to happen much more frequently.

Plus, now, if you want to go back to an independant stylesheet (because, say, you moved to web components and isolated the legacy content there), you have to go back and remove all the & symbols since they don't mean anything anymore. If you had used proposal 4 or 5, you would not need to do this.

There are proposals to give & meaning everywhere and to allow relative selectors everywhere.

• [selectors][css-nesting] Move nest-containing and nest-prefixed selector definitions to Selectors #5745
• [css-selectors] Allow relative selectors everywhere #8010

Not saying that that is a reason not to pick 4 or 5.
But it is something that isn't made impossible simply by choosing 3.

I would also like to point out that with autocompletion these days, you hardly ever write a } yourself. They are auto-inserted. The actual workflow when adding nested rules is more likely to be "click after the } and type { then your rules".

Ah, yes, I forget about that because I disable this behavior.

A smart IDE could unemphasize these two braces with a different (less-contrasting) coloring,

Could even be a ligature like we have for !==

We closed this issue after polling developer's opinion on the issue.

Only around 20% of developers prefered not keeping the SASS-like syntax to avoid suffering from code portability issues, and about half of the remaining 80% advocate for a mandatory prefix before selectors, which destroys any hope of code portability. Based on this, we can assume a 20% vs 40% ratio against trade-offs for code portability, which makes the efforts of option 4 and 5 moot on this aspect.

I'm closing this issue as a result.