Thank you @LeaVerou.

As a design principle, I don't think CSS should have author-facing syntax that provides no benefit to authors. Either we should come up with actual use cases for @nest

I actually want the @nest rule but as a more generic organizational tool.

In JavaScript it is possible to write blocks without any condition. I use this very frequently to group bits of code in a larger section.

This new at-rule could serve a similar purpose. Most authors will never use it but they could to organise and structure their code.

Today we use either multiple rules with the same selector, or comments when we want to group lists of declarations. Neither is really good.

This is our list of custom props when we start a new project :

:root {
	/* #region Colors */
	--color-foreground: rgb(0 0 0);
	--color-background: rgb(255 255 255);
	--color-grey-40: rgb(108 112 108);
	--color-warning: rgb(242 149 0);
	--color-error: rgb(207 0 0);
	/* #endregion Colors */

	/* #region Typography */
	--font-sans: "Helvetica Neue", sans-serif;
	--font-serif: "Georgia", serif;
	/* #endregion Typography */

	/* #region Spacers */
	--space-1--px: 1px;
	--space-1--rem: 0.0625rem;
	--space-8--px: 8px;
	--space-8--rem: 0.5rem;
	--space-16--px: 16px;
	--space-16--rem: 1rem;
	--space-32--px: 32px;
	--space-32--rem: 2rem;
	--space-48--px: 48px;
	--space-48--rem: 3rem;
	/* #endregion Spacers */
}

We need to add comments before and after each group so that we can have folding regions in code editors.

@tabatkins has also stated that they aren't attached to the name of this at-rule. Something that isn't tied to nesting would be nice.

If on the other hand, this can all be implementation details, then I prefer that.
I however fear that we can only kick this bucket further down the road and that some API will surface the warts.

In JavaScript it is possible to write blocks without any condition. I use this very frequently to group bits of code in a larger section.

@tabatkins has also stated that they aren't attached to the name of this at-rule. Something that isn't tied to nesting would be nice.

Do we need the @nest part of the rule? Can we use naked {}? Looking at css-syntax, I don't immediately see why not. In other words:

:root {
  /* #region Colors */
  {
    --color-foreground: rgb(0 0 0);
    --color-background: rgb(255 255 255);
    --color-grey-40: rgb(108 112 108);
    --color-warning: rgb(242 149 0);
    --color-error: rgb(207 0 0);
  }

  /* ... etc ... */
}

fixing the specifics is more web compatible than changing the current behavior after even longer.

To be clear, this issue blocks actually carrying out #8738. The more we mess around with the details here, the higher the risk that no change will happen at all.

To be clear, this issue blocks actually carrying out #8738. The more we mess around with the details here, the higher the risk that no change will happen at all.

That was not the resolution at all. Please implement the @nest rule as currently specced by @tabatkins. It is far, far easier to change the details of that than to change the current behavior of nesting later. That's the whole point of the resolution we made on Wednesday!

@LeaVerou Oh. I thought the point of the resolution was to focus the discussion and hopefully converge on something.

Unfortunately I can't make a move on @nest until this issue is resolved. I will likely not be able to ship a breaking change with the intent to break it again later, especially when there's no consensus on what the follow-up change would be.

It is far, far easier to change the details of that than to change the current behavior of nesting later.

The specific changes we're discussing here can not necessarily be made later at all. It is sometimes very hard to understand the risk of changing CSSOM APIs.

@andruud It's not with the "intent to break it again later". It's with the intent to keep @nest as a better option than the "shifting up", but leaving the door open to explore other possibilities.

The specific changes we're discussing here can not necessarily be made later at all.

If later on we prefer to switch to something else but it's not compatible, then so be it, we can stay with @nest.

The point is that there was consensus that @nest is better than "shifting up". Exploring other possible approaches shouldn't block @nest, since delaying it will just make it not compatible.

As I said in my final comment in 8738, when considering any new feature, or additional complexity in an existing feature, it's worth paying attention to both the size of the affected audience and the size of the benefit that audience will receive.

The existence of an @nest rule is visible solely to authors who are crawling the CSSOM, or serializing the OM and then looking at it. Both of these are advanced use-cases, they're not something that 99% (and I think that's a very conservative percentage) of authors will ever do. I, myself, have never inspected the CSSOM in my entire webdev career except when writing WPTs.

So, the audience of people affected by any change here is very tiny, I'll argue, and that audience is composed of relatively skilled authors. (I think this audience can be reasonably summarized as "people who are writing CSS tooling".)

Do any of these changes allow that audience to do something currently difficult or impossible? No, these are solely attempting to improve the consistency of how the OM is represented in certain aspects.

Do they improve this audience's experience in a meaningful way? Arguable. While they improve the consistency in some ways (making the OM and/or the reserialized string more closely resemble the originally authored code), they reduce consistency in other ways (unusual serialization rules; edge cases that require restrictions on where rules can be moved around; widening of the possible types in certain attributes).

For example, right now you can, in theory, take any of the objects in an MQ's .cssRules list and move it out of that MQ, appending it to the stylesheet itself. If the object here is a CSSStyleDeclaration, what happens? Is that an error? If it's a CSSNestRule, but we have special serialization rules that make it look like raw declarations, how does it serialize in this case? (Or, again, maybe it causes an error?)

Or take .insertRule(). Its first argument is a string, which is parsed to obtain a rule to insert. (You can pass a rule object directly, but it's serialized and then re-parsed.) If you can't write @nest directly in a stylesheet, how do you insert such a rule? Do we have to now accept code like x.insertRule("color: blue;"), which is invalid today?

Or a parsed stylesheet will never have an @nest at the start of a style rule, or next to each other. But via CSSOM manipulation you can construct such situations. How do they serialize? Will you still end up with a stylesheet that parses into a different OM than it started from

Whatever we do, if it's "magic" in some way, it'll spawn corner cases like this. Magic like this can be justified, by sufficient benefit to a sufficient audience. I don't think that it qualifies on either metric in this case, however.

In summary, we should just do the simplest possible thing, with the least amount of magic possible, because all of the suggested magic (beyond the initial parser magic) won't actually pay for itself.

Do we need the @nest part of the rule? Can we use naked {}? Looking at css-syntax, I don't immediately see why not.

We could, it would just be a new syntax construct to define. Relying on the existing at-rule syntax just makes for a slightly simpler model. And since we don't anticipate authors actually writing this themselves, I don't think the length of the name actually matter in any meaningful way.

@andruud

@LeaVerou Oh. I thought the point of the resolution was to focus the discussion and hopefully converge on something.

Unfortunately I can't make a move on @nest until this issue is resolved. I will likely not be able to ship a breaking change with the intent to break it again later, especially when there's no consensus on what the follow-up change would be.

It is far, far easier to change the details of that than to change the current behavior of nesting later.

The specific changes we're discussing here can not necessarily be made later at all. It is sometimes very hard to understand the risk of changing CSSOM APIs.

We are trying to avoid a breaking change by shipping @nest in some shape or form. @tabatkins is arguing right under your comment that how we implement this in the OM only affects a tiny fraction of authors. You are saying that it would be a breaking change and that "it’s very hard to understand the risk of changing CSSOM APIs". It may be productive if you two have a breakout to align on this, since you work at the same company? Because unless I’m missing something, I don't see how both statements can be true (it is both impactful and not impactful).

@tabatkins

As I said in my final comment in 8738, when considering any new feature, or additional complexity in an existing feature, it's worth paying attention to both the size of the affected audience and the size of the benefit that audience will receive.

Tab, nobody is disagreeing that I/E matters, we’re disagreeing on what the I is.

The existence of an @nest rule is visible solely to authors who are crawling the CSSOM, or serializing the OM and then looking at it. Both of these are advanced use-cases, they're not something that 99% (and I think that's a very conservative percentage) of authors will ever do. I, myself, have never inspected the CSSOM in my entire webdev career except when writing WPTs.

I have responded to this point in the OP:

I strongly disagree with Tab that reading and modifying the CSS OM only affects about a hundred developers in the entire world (!). Reading and modifying the CSS OM is at the core of a ton of very widespread libraries (e.g. jQuery, D3, etc). Even if most authors do not use it directly, I assure you almost every developer reads and modifies the CSS OM regularly, it's just done through several layers of abstractions.

Also, since we’re sharing anecdotes, I have crawled and modified the CSS OM dozens of times in my web dev career, none of which was while writing WPTs. I did not mention it earlier because as an anecdote, I didn’t think it was that relevant.

So, the audience of people affected by any change here is very tiny, I'll argue, and that audience is composed of relatively skilled authors. (I think this audience can be reasonably summarized as "people who are writing CSS tooling".)

Again, the users of these tools are not a small audience.

For example, right now you can, in theory, take any of the objects in an MQ's .cssRules list and move it out of that MQ, appending it to the stylesheet itself. If the object here is a CSSStyleDeclaration, what happens? Is that an error? If it's a CSSNestRule, but we have special serialization rules that make it look like raw declarations, how does it serialize in this case? (Or, again, maybe it causes an error?)

I don’t see how this is different than defining what @nest {} does in the root scope. We’ll have to define something however you look at it. And if anything, defining what root-level declarations do is actually quite useful (anecdotally, I’ve written special code to handle raw declarations at the root level several times when coding CSS demos).

Actually, depending on how we define it root-level declarations could even solve all these use cases that require setting stuff on the document node.

Or take .insertRule(). Its first argument is a string, which is parsed to obtain a rule to insert. (You can pass a rule object directly, but it's serialized and then re-parsed.) If you can't write @nest directly in a stylesheet, how do you insert such a rule? Do we have to now accept code like x.insertRule("color: blue;"), which is invalid today?

Yes! Which again seems like a win and more broadly useful.

Or a parsed stylesheet will never have an @nest at the start of a style rule, or next to each other. But via CSSOM manipulation you can construct such situations. How do they serialize? Will you still end up with a stylesheet that parses into a different OM than it started from

I’m not married to the details, but I was envisioning that these nodes would be merged automatically by the CSS OM, not during serialization. All the Web Platform’s OMs are full of these kinds of normalizations, so I don’t see what the problem is.

The users of tools that crawl/modify the CSSOM only matter for this proposal insofar as those tools expose the CSSOM to them (or this proposal makes those tools work better, thus improving the experience of their users). Do you have examples of that?

I don’t see how this is different than defining what @nest {} does in the root scope.

Sure, we have to define what @nest does in the global scope, in exactly the same way we defined what & matches in the global scope. (And it's currently defined to act exactly the same.) But these additional things are more corner cases to define.

Yes! Which again seems like a win and more broadly useful.

How is this a meaningful win over x.insertRule("@nest { color: blue; }")? I mean, it's very slightly shorter, sure. But does it matter otherwise? Is it worth the consistency loss of insertRule() no longer being restricted to taking rules?

I’m not married to the details, but I was envisioning that these nodes would be merged automatically by the CSS OM, not during serialization. All the Web Platform’s OMs are full of these kinds of normalizations, so I don’t see what the problem is.

I don't think that's accurate to say. For example, in the following:

<!DOCTYPE html>
<p>
<script>
var p = document.querySelector("p");
p.appendChild(new Text("foo"));
p.appendChild(new Text("bar"));
console.log(p.childNodes);
</script>

You'll get two Text nodes, despite that being essentially identical to just having a single Text node with "foobar". Having nodes magically merge underneath you as a side-effect of doing something unrelated (like removing a rule that previously happened to separate two of them) is the sort of thing that causes bugs in author code very easily, since objects disappear, indexes change, etc. in an unpredictable manner.

Do we need the @nest part of the rule? Can we use naked {}? Looking at css-syntax, I don't immediately see why not.

We could, it would just be a new syntax construct to define. Relying on the existing at-rule syntax just makes for a slightly simpler model. And since we don't anticipate authors actually writing this themselves, I don't think the length of the name actually matter in any meaningful way.

Yeah, sure. {} was a response to @romainmenke's world where authors might actually want to write it themselves. If @nest{} basically does nothing (except add structure), perhaps {} is a better way to represent it (and more in line with other languages).

Because unless I’m missing something, I don't see how both statements can be true (it is both impactful and not impactful).

That is not what I'm saying. I'm saying it's not always easy to prove that CSSOM changes won't break sites, even if you strongly believe it won't.

But OK, if shipping @nest ASAP is indeed what everyone wants here, I can try. I'll need positions from Apple and Mozilla. (EDIT: mozilla/standards-positions#1013, WebKit/standards-positions#337).

If we have author facing syntax for this, I'd prefer it's not {} so we can reserve {} for something that is actually useful (of course this changes if we can figure out a way to make @nest {} useful).

But OK, if shipping @nest ASAP is indeed what everyone wants here, I can try. I'll need positions from Apple and Mozilla. (EDIT: mozilla/standards-positions#1013, WebKit/standards-positions#337).

Thank you!

One question that would affect my opinion of whether the CSSOM questions here matter: what's the chance that at some point in the future we'll allow the nesting syntax inside the style attribute? (This sort of syntax has been proposed and specified in the past, but it didn't get traction at the time.) I think the CSSOM is much more relevant for the style attribute than it is for style sheets, since it's more widely used there.

3. No @nest, just CSSStyleDeclaration in the CSSOM
   • Criticism: That means .cssRules will also return non-rules? Would .insertRule() also accept CSSStyleDeclaration?

I am not sure I understood the whole conversation between mdubet and emilio about this in #8738, but intermixing list of declarations (or CSSStyleDeclarations) and rules in specified order in an internal property (eg. contents) seemed like an idiomatic solution.

The first list of declarations in contents should be exposed by style. .cssRules and .insertRule() should ignore lists of declarations in contents. .deleteRule() should eventually move declarations into the first list. It does not seem that painfull.

I did not understood why contents would need to be exposed by the public .cssRules. I guess in order to add declarations after rules via the CSSOM. Assuming there is a need for this, a new interface like .insertDeclaration() and/or styles could be defined.

But accepting declarations in .insertRule(), ugh. 😬

One question that would affect my opinion of whether the CSSOM questions here matter: what's the chance that at some point in the future we'll allow the nesting syntax inside the style attribute? (This sort of syntax has been proposed and specified in the past, but it didn't get traction at the time.) I think the CSSOM is much more relevant for the style attribute than it is for style sheets, since it's more widely used there.

My understanding is that this is basically planned, and it's just a matter of resource allocation. Inline style nesting is a huge use case.

Since it seems hard to get consensus on making this rule less author facing, could we explore going the other way? I.e. keeping is as author-facing, and trying to make it useful in some way.

Some ideas:

• Someone mentioned that it could be used for grouping. That definitely makes sense. Other threads discuss a potential @sheet rule that basically does named grouping. I wonder if these two could be combined.
• Keeping fallbacks around that can be used for IACVT
• Simple style() conditionals on the current element? Or some other way to toggle these groups on or off or pick among two?

Just brainstorming here. What would be some low hanging, easy-ish to implement functionality that could make this rule actually useful?

Perhaps we should simply name it @group and allow an optional <dashed-ident> before the {, then we can figure out later what these can be used for.

I did not understood why contents would need to be exposed by the public .cssRules. I guess in order to add declarations after rules via the CSSOM. Assuming there is a need for this, a new interface like .insertDeclaration() and/or styles could be defined.

You really want authors to be able to see all the styles in the stylesheet, in the right order. If cssRules doesn't do that you need something else.

Another thing to note, not sure how well this interacts with @scope... @andruud / @dshin-moz / @tabatkins / @mirisuzanne, do you know off-hand?

IIRC we either stash an implicit :scope in the selector (but we can't with @nest, because there's no selector), or use the & which now includes the start bound, right? At least I recall a weird interaction between nesting and @scope, but I don't recall the specifics...

That is, what does:

#a {
  ...

  @scope (#b) {
    color: red;
  }

desugar to now? What would desugar to with @nest and would it work correctly?

@emilio Nothing different for @scope than the other nested group rules : we currently wrap the declarations in & which desugar to :is(#b) (because the <scope-start> acts as a parent selector).

Exploring the use cases for a more general @group rule is a good path forward (even just changing the name to anything less specific than @nest is a progression imho)

Oh, so the fact that the scope rule is inside the #a selector is completely lost already? That's a bit weird / unintuitive but ok I guess

completely lost

Maybe it's not what you meant, but it's not completely lost, it's in the implicit & in the <scope-start>:

#a {
  ...
  @scope (& #b) {
    @nest {
      color: red;
    }
  }

I think that will be just fine.

Perhaps we should simply name it @group and allow an optional <dashed-ident> before the {, then we can figure out later what these can be used for.

I support this too.

Although we could easily add a <dashed-ident> to the prelude later, if/when we have a good reason for it. Maybe we just ship @group {} for now, leaving the prelude wide open for whatever we come up with later.

Ah, cool, It's added to the start of the scope, that seems fine then I agree.

I don't mind calling it @group (but if we do so then it probably should be a grouping rule after all, and not be restricted to declarations...)

I don't mind calling it @group (but if we do so then it probably should be a grouping rule after all, and not be restricted to declarations...)

Yes, agree.

So authors could (but likely won't) write :

:root {
  @group {
    --color-a: pink;

    @media screen { --color-a: red; }

    --color-b: lime;
  }
}

Which would be equivalent to :

:root {
  @group {
    --color-a: pink;

    @media screen { --color-a: red; }

    @group { --color-b: lime; }
  }
}

Although we could easily add a <dashed-ident> to the prelude later, if/when we have a good reason for it. Maybe we just ship @group {} for now, leaving the prelude wide open for whatever we come up with later.

The thinking was to support this kind of usage.

It would be nice though if we could come up with some actual useful functionality for these groups other than simple grouping. Are any of the things I mentioned here feasible?

To be clear, this issue blocks actually carrying out #8738. The more we mess around with the details here, the higher the risk that no change will happen at all.

That was not the resolution at all. Please implement the @nest rule as currently specced by @tabatkins. It is far, far easier to change the details of that than to change the current behavior of nesting later. That's the whole point of the resolution we made on Wednesday!

With WebKit's position now clarified, and after some feedback on the Blink Intent-to-Ship, it's pretty clear that this issue is in fact blocking #8738.

This is a long-shot, not well thought-through - but is there a way for named-group declarations to be available as a form of name-spaced custom property. I don't think this would provide actual new functionality, but some syntax shortcuts for name-spacing and declaring a custom/standard property at the same time:

.now {
  --base-padding: 1em;
  padding: var(--base-padding);

  --color-primary: teal;
  --color-secondary: hotPink;
}

.groups {
  @group --base {
    padding: 1em;
  }

  @group --color {
    --primary: teal;
    --secondary: hotPink;    
  }
  
  .access {
    margin: var(--base.padding);
    border-color: var(--color.--primary);
  }
}

(Hope I'm not straying too far from the question at hand - but it seems like an otherwise-useful rule might help with WebKit's concerns?)

That's fair. One thing that makes me wonder about is if that would end up invalidating some implementation assumptions. Such as that

background:red;
background:lime;

would only give a single background declaration within what is conceptually a single declaration block. Seems manageable though.

And the reason we made this trade-off is because we are willing to accept a slightly less nice CSSOM (which is already quite terrible with all its string-based APIs and reportedly only used by 1% of web developers) to the benefit of all other web developers.

I don't quite understand this reasoning, tho - the effects of this are, as far as I can tell, only really observed by people doing the same sort of CSSOM manipulation. You'd only see it if you're stringifying rules and looking at the result. Do you have an example use-case where the stringification helps other people outside of CSSOM-manipulators?

This is the reason I keep harping on (a) the audience and (b) the benefit - I still don't think this has been adequately argued for.

If you introduce a new at-rule, it will show up in lists of at-rules, and people will wonder what it's for. People will encounter it here and there and have to look up what it means, etc. I.e., you add to the complexity of CSS syntax.

Right, so we're judging the balance of one authoring cost (having to bear the psychic weight of knowing this do-nothing rule exists, if you're the sort of person who reads lists of at-rules) vs another authoring cost (having to deal with more complicated/magical behavior for several OM methods), plus the impl/spec cost of that magic. (And the future spec cost of having to engineer around this magic; as I said above, I think this would block us changing to an ObservableArray for .cssRules, or at least make such a switch way more complicated and fragile.)

I think "knowing a do-nothing rule exists" is a lot less pain than "dealing with weird behavior when doing rule-tree manipulation".

(I speak from experience here; I reimplemented most of the DOM for myself in Python, even with all its warts, because the XML library I'm using in Bikeshed has a terrible data model where text is different from other nodes, and many of its methods have odd magic behavior in the same vein as what's being suggested here. I kept accidentally writing broken code as a direct result of the magic (text would get deleted, or duplicated, or moved in unpredictable ways), so using the DOM and its shitty but simple and consistent "everything is a node" behavior was way better.)

I imagine tutorials would just look something like:

@nest rules: sometimes implicitly produced by the CSS parser when you're mixing declarations after rules. You can write it yourself, but it doesn't actually do anything. Most of the time CSS doesn't serialize them, either, so you'll only see them if you're using them manually, or manipulating the CSSOM directly.

We can also make the name much less attractive and more obviously internal, if that would help, like @implicit-nested-properties-group {...} or something. Slightly on the ridiculous side for length, so it's not something an author would ever reach for when writing code manually, but also a very descriptive name that suggests what it's doing immediately, and is much easier to google for.

If WebKit keeps objecting to @nest, instead of making CSSOM nonsensical, I would prefer revisiting #10234 (comment):

• Instead of a new @nest, use an existing at-rule like @media or @supports
• This implies changing that at-rule to accept declarations without any intermediate structure (analogous to CSSStyleRule)

If WebKit keeps objecting to @nest

Both Blink and WebKit are objecting here (to different things). If only one was objecting, we would be able to move forwards. Blink is also being inflexible here.

At this point, I'd be fine with anything, because we're fast approaching the point where we'd be stuck with the hoisting behavior, which is worse than any proposed solution.

If we go the route of a new @-rule, I did propose naming it @group which is something not tied to nesting, that we can layer behavior on top of later.

I still like the @group proposal but I also wonder if we would design this exact thing if we didn't need it to patch the wart for nesting.

Would we actually spec @group tobikeshed { } with the IACVT behavior?
Or would we pick something more like @fallback { }, @catch { } or even extend @try { }?

If @group <ident> {} is something we want anyway then it would be good if WebKit could give feedback on this proposal. They only gave feedback on @nest {} and specifically on it having no purpose. Exactly this feedback was already addressed by the @group {} proposal.

My understanding is that Blink and Gecko are both on the same page, in terms of how to best move forward...

@romainmenke This is about the name, any <ident> behavior would be added later. L1 would be just @group {}.

@emilio My understanding from the conversations so far though is that it's Blink that is being inflexible though; Gecko agrees with Blink, but is willing to go a different route if we have consensus for it.

The objection from WebKit is that @nest {} doesn't have a purpose other than fixing this wart. @group {} ultimately has the same issue unless we already commit to giving it a purpose later. I am not sure we should be designing new syntax in this order.

In this way I also agree with @tabatkins when they said:

We can also make the name much less attractive and more obviously internal, if that would help, like @implicit-nested-properties-group {...} or something. Slightly on the ridiculous side for length, so it's not something an author would ever reach for when writing code manually, but also a very descriptive name that suggests what it's doing immediately, and is much easier to google for.

Precisely, the objection is that @nest {} doesn't have any purpose other than fixing this wart and will not have one in the future neither because the name is very specific (and confusing with the nesting selector).

EDIT: This doesn't imply at all that we would accept @group or @very-weird-name (because as Romain said, they have the same issue of extending the CSS syntax for no reason except this wart). My comment just reiterates the multiple reasons we have rejected @nest.

@LeaVerou To clarify, I wasn't trying to blame WebKit for not being able to move forward. With "keeps objecting" I meant if possible mitigations like #10234 (comment) don't convince them to drop the objection to @nest.

I think I prefer @some-weird-name to @group, because if authors somehow do find a use for it that is different or more specific than grouping or nesting, we can replace/alias the weird name with something more closely matching the discovered use.

Could someone who believes @nest is a good solution, please answer this question… pretend a community college professor is emailing you, and asks: "I want to teach my students to use CSS Nesting. Could you explain when / how / where they should use the new @nest rule? What does that nested CSS look like?"

I want to teach my students to use CSS Nesting. Could you explain when / how / where they should use the new @nest rule? What does that nested CSS look like?

I don't see what the issue would be with an answer like "You should never need to write @nest manually, it gets added where needed by the CSS parser."

@emilio It's necessary to write manually if you're using .insertRule() though, isn't it?

Also people still write </p> even though it has always been added where needed by the HTML parser. I think we can expect the same for @nest and similar once it exists.

Sure, it would if you're calling insertRule or so.

I don't see how this compares to </p>. Omitting closing tags in HTML is the exception, while the intuitive syntax for CSS nesting would be the rule.

It's necessary to write manually if you're using .insertRule() though, isn't it?

As I keep arguing, that's a very advanced usage. You don't teach people how to use .insertRule() (or really any of the OM except .style, probably) in a beginner CSS course. It's something needed extremely rarely, for advanced CSS tooling use-cases only. (Personally, I have never, not a single time, used it in my own webdev.)

And, as I've argued, the cost of "when I, a CSS tooling author, use .insertRule(), I have to insert a rule of some sort (and @nest, or whatever we call it, is the easiest) to insert a block of declarations between two other rules" is more than outweighed by the benefit of "when I, a CSS tooling author, do arbitrary manipulations to the OM, everything works in a simple and expected way, and the structures appear in close correspondence with the method calls I make".

(Plus, we could certainly still add .insertDeclarations(), which creates the rule for you automatically. If that's a use-case we want to make easier, I think that's a very reasonable thing to do. It's roughly neutral on typing (longer method name, but you don't need to add the @nest{ and } prefix/suffix to your string), but it does communicate intent well.)

Could someone who believes @nest is a good solution, please answer this question… pretend a community college professor is emailing you, and asks: "I want to teach my students to use CSS Nesting. Could you explain when / how / where they should use the new @nest rule? What does that nested CSS look like?"

I wrote something to this effect in my previous comment.

I think I prefer @some-weird-name to @group, because if authors somehow do find a use for it that is different or more specific than grouping or nesting, we can replace/alias the weird name with something more closely matching the discovered use.

Not sure about getting stuck with @some-weird-name for time immemorial though. I think @group is sufficiently generic that it can work decently with any use.

The CSS Working Group just discussed [css-syntax][css-nesting] Design of `@nest` rule, and agreed to the following:

• RESOLVED: 1. Introduce a CSSNestedDeclarations object inheriting from CSSRule and having a .style accessor, and use that to represent the declaration lists in a CSSStyleRule. It serializes as a raw declaration list. 2. Extend .insertRule() to parse declarations (or, if Web-compat requires, add .insertDeclarations()) into a CSSNestedDeclarations Object. 3. Open a new issue wrt the first declarations block.

Possibly too late to change the design, but I just had an idea: What if we do introduce the rule, call it @group, and instead of introducing identifiers in the preamble, we have a revert-group value that would work similarly to revert-layer, i.e. would revert the declaration to what it would have been if the group was not applied.
Then groups have a purpose that is not turned on by default (making them suitable for representing nested declarations) but is still super useful: they allow authors to override the IACVT behavior with an actual fallback! This is especially useful in combination with something like if():

@group {
	border-radius: if(style(--button-shape: pill), infinity, revert-group);
}