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

@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](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.

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 ](https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-2061808429) (!). 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.







-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10234#issuecomment-2070985010 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 21:30:06 UTC