Re: [csswg-drafts] [css-syntax][css-nesting] Design of `@nest` rule (#10234)

Okay, so rephrasing the proposal a bit to make sure I understand it:

1. At parse time, raw decls get grouped in a new `CSSNestedDeclarations` object, which is put into the `.cssRules` of the parent at the appropriate place. This includes the *initial* decls.
2. `CSSNestedDeclarations` only has a `.style`, and serializes as its declarations.
3. I'll assume they're inserted with a new `.insertDeclarations()` method on `CSSGroupingRule`. This has some special magic to check if, either before/after the insertion point, there's already a `CSSNestedDeclarations` object; if so, it'll append/prepend the decls into that object rather than creating a new one. 
 * This means that passing a rule to `.insertDeclarations()` will fail, and passing a declarations to `.insertRule()` will fail, since they each serialize as the wrong thing that won't parse right.
5. `.deleteRule()` still works on `CSSNestedDeclarations`.
6. `CSSStyleRule`'s `.style` accessor redirects to the `.style` of the `CSSNestedDeclarations` at index 0 of its `.cssRules`.
7. (Maybe we add `.style` to `CSSGroupingRule`, then, so `@media`/etc get that too?)

There are two issues I see:

* It sounds like a rule's *initial* declarations get stored into a `CSSNestedDeclarations`, and `.style` on the parent rule redirects to that, *including when there aren't any declarations* (you'll get an empty one). But this isn't backwards-compatible with `@media`/etc, if their contents currently start with a nested rule (which they *all* do, today). We'd need to do *more* magic to only create the initial `CSSNestedDeclarations` *if* there were initial declarations, and make `.style` on the parent still work *and* auto-create+insert a `CSSNestedDeclarations` if you set a property on it.
* Closely related: what happens if you `.deleteRule()` the initial `CSSNestedDeclarations`? Presumably would need to fall into the same behavior as above, and magically re-create one as soon as you set a property.

-----------

Most importantly, tho, my actual pushback wasn't on the details of the behavior, it was on the *justification* - what audience is affected by this, and how much benefit they are getting from it. This wasn't addressed *at all* in [Elika's comment](https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2116380146). 

I continue to argue that (a) the audience for any of this is miniscule (just advanced authors, mainly tool authors, that actually crawl/manipulate the CSSOM structure in non-trivial ways), and the benefits are *mixed at best*, and don't actually solve any meaningful problems for authors.

Seriously, the pros:
* When you look at the serialization of a rule/stylesheet, it looks slightly better.

The cons:
* We get a new type of `CSSRule` which can't be inserted into all `CSSRuleList`s, only those of parent rules. (Or we get a new object that isn't a subclass of `CSSRule`, and then `.cssRules` now contains things that aren't `CSSRule`s.)
* We get a new insertion method, which magically *sometimes* inserts a new rule and sometimes merges into an existing rule.
* If you want to, say, transfer all the child rules from one rule to another, you have to test each child rule and select the correct insertion method.
* We get new behavior for .deleteRule, where it sometimes doesn't delete a rule. (Or rather, it deletes the rule and then immediately replaces it.)
* We get complex new behavior for `.style`, where it might magically create a new rule when you interact with it.
* We're either blocked on ever improving the `CSSRuleList` interface into being an ObservableArray (where you can just move the rules around), or have to add all the weird magic into *it* as well.

If the above is accurate, then this approach is still unjustified. I strongly object to doing it unless/until @fantasai can show that there are reasonable benefits that outweigh the downsides, and are meaningful to a large enough audience. This has not yet been demonstrated.

(I mean, we decline to add things that are minor conveniences to a miniscule audience *all the time*, when the only cost is that it's a little bit of extra impl effort but not actually complex. See, for example, all the things we regularly reject from Values&Units. This proposal has *real* complexity costs associated with it, so it's clearly a CLOSED WONTFIX in my book unless there's something major I'm missing.)

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2123168764 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 21 May 2024 18:08:10 UTC