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

As I said in [my final comment in 8738](https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-2061808429), 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.

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


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

Received on Monday, 22 April 2024 20:44:26 UTC