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

> [citation needed] Do you have any data to back this claim up? And it is a 90/10 majority or more like a 51/49 majority?

Most selectors in the wild are based on classes, pseudo-classes, or attributes, just as a rule. Element selectors are a minority in complex selectors.  And to be problematic for our purposes, the element selector has to be part of the first compound selector in the nested rule's selector, and the nested selector has to be either non-relative, or relative with an implicit descendant combinator.

For confirmation you can just go look at the CSS from a random collection of popular websites.

> So given the fact that there's a real cost to pay to for one of the solutions, doesn't it make sense to get this data before making a binding decision and shipping code? Particularly if that data may allow us to resolve all the issues and deliver a solution that makes everyone happy and covers 100% of the use cases?

There is a cost to pay for *all* syntax options. In a significant way, the major decision is whether we're pushing the cost to all authors (requiring a more verbose syntax) or to future spec authors (requiring more careful syntax design in the future). As I've argued, I think the latter cost is actually extraordinarily small in practice.

> If we know for a fact that the better way of doing can't be done at all, or maybe not for another decade or so, then the push for delivering something makes more sense.

Again, the current spec is pretty trivially switchable into an unlimited-lookahead syntax. All other approaches require us to be left with a legacy syntax *in addition to* the unlimited-lookahead syntax. So if we want to ship something ahead of confirmation (or denial) that unlimited-lookahead is viable, the current spec is still the best way to do so.

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


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

Received on Friday, 13 January 2023 20:40:22 UTC