Re: [csswg-drafts] [css-cascade] [css-nesting] Figure out whether we're fine with "shifting up" bare declarations after rules (#8738)

To reiterate my points a bit from the call:

* Fixing this problem *in any reasonable way* will affect (positively) approximately all CSS authors (by making properties in MQs/etc work better), and unblock CSS from evolving in certain ways that we want it to (adding mixins). 
* The issues brought up in the latter half of this thread are exclusively about the CSSOM, specifically reading and modifying it. I, personally, have never *once* read or modified the CSSOM in my entire webdev career; I've only ever done so to write WPTs.
* So, to a first approximation, these issues affect nobody. ^_^ More precisely, the only audience I know of that actually reads/modifies the CSSOM in non-trivial ways (more than just, say, serializing an entire stylesheet and putting it somewhere else) are *CSS tool authors*. I'd estimate there to be *a few hundred* people in this category, across the entire world; a thousand on the extreme end of the possible range. This audience is also going to be significantly more experienced with coding in general.
* None of the issues listed here are about a use-case being *difficult* or *impossible*, which is usually what we can use to justify solving a use-case for such a small audience. They are convenience features.
* And the convenience itself is arguable in most cases. They're mostly about making the OM more *consistent* in some ways, but every single one comes at the cost of making it *less consistent* in other ways.

So in summary, past the necessary complexity/magic that's at the core of the issue (grouping interleaved declarations in some way so they don't merge with the initial set of decls), *any* further complexity we add is, as far as I can tell, solely to add minor convenience to some use-cases for a miniscule audience of already-experienced developers. Thus, none of them justify the spec and impl complexity cost they would impose.

I'm more than happy to be shown wrong on this regard - if you have an example of some change to [my base proposal](https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-2057868087) that would either give the "CSS tool authors" audience a *large* benefit (especially if it unblocks something that is currently hard or impossible), or that would give the "CSS general audience" even a mild benefit, or that would give some third audience I'm not aware of a benefit that is appropriately weighted against its size, then I'd joyfully consider it.

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


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

Received on Wednesday, 17 April 2024 17:20:36 UTC