Re: [csswg-drafts] [css-nesting] Problem with mixing properties and selectors (#8249)

> .foo { color: red; @nest .bar {...} background: blue; }

Is not broken, old browsers see the `@nest` as a rule and accept the background property. Try it.

> Also, if an author does want to limit the theoretical damage, they can either (a) put their properties before the nested rules, as the spec recommends

Seriously, how many authors actually read specs? There are all sorts of best practices listed in specs that hardly anyone uses. They mostly cargo-cult things they see elsewhere and there have been tons of common practices in the past that were exactly the wrong thing to do.

It's not about whether knowledgeable authors can limit the damage, it's about the rest of the authors that will be surprised by the unexpected behavior.

> Can you give an example of a stylesheet where an author might add nested styles that they are okay with not applying?

```css
div[this=that].something:open {
    span { box-shadow: 5px 5px 5px #888; } /* This is decorative and I don't care if this applies or not, but I don't want to repeat the long parent selector because people said DRY and nesting is cool */
    background: black; /* I didn't read the spec and I like to put nested rules first because I find it easier to read */
    color: white;  /* surprise! white on white text for several billion users on cheap devices that can't upgrade yet that I never considered or tested on */
    ....
}
```

> both more flexible for authors and less restrictive on future design

The look-ahead approach is not more flexible than an at-rule, just slightly less typing, and an at-rule is less restrictive, see above.

> This WG's work cannot be indefinitely held up by endlessly relitigating existing resolutions without new data

My point is that *there is new data*. Several of the points I've brought up recently about language design restrictions and error recovery came as a surprise to several members on recent calls, including those who participated in past decisions. That merits a re-evaluation. Several of the early decisions on syntax were mostly based on preferences and did not weigh all the consequences, because they weren't all well known by those expressing their preference. 

Also, we can spend far more time debating whether we should be debating this, than simply laying out all the options, the plusses and minuses of each, and just making a call (and not considering inertia or 'shipped' implementations which were never signed of on by the WG). So let's just do that. I'm willing to live with the outcome of that whatever it is, are you?

> Continuing to imply that this is me, personally, ramming things thru the WG, ...

I'm not intending to imply that it's you personally ramming things through the WG, apologies if I came across that way. However several people have been trying to force resolutions on nesting without proper notice or time for discussion. Several decisions have been rushed and several times people were unwilling to revisit past decisions even after new information was brought forward. I'm not the only one who's observed 'go-fever'.

You have been expressing your personal opinions about the relative importance of issues, which it totally fine, but those doesn't necessarily represent WG consensus (neither do mine) so can't settle a disagreement on their own. I accept I wasn't part of every historical conversation about nesting, so if I'm interpreting something as a personal opinion where there is WG consensus, please feel free to point me to the minutes and resolutions.

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


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

Received on Thursday, 6 April 2023 01:45:12 UTC