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

Given the speculation about my position it's probably worthwhile for me to be a bit more clear where I stand.

All of the work on nesting up until recently has been done under the presumption that adding lookahead to the parser couldn't be done. To this end there has been a lot of work trying to find a compromise syntax that serves everyone's needs. There has obviously been a lot of work and a lot of creativity put into this effort. I'm not belitting that in the least, but at the end of the day the outcome is that we've fairly well determined that there *isn't* a solution without lookahead that meets all the requirements. At best we have a compromise solution that I've heard described as "the least worst solution" (which I actually disagree with, but more on that later).

The one thing we haven't spent any energy on (until the last couple of weeks), is exploring the solution of 'simply' relaxing the lookahead restriction. I feel there's broad consensus that doing so *does* allow us to deliver a nesting syntax that is an optimal solution and makes everyone happy, especially authors who are used to SASS.

The lookahead restriction is over 25 years old at this point, and serves no purpose except parsing perfomance. I worked on Gecko's first CSS parser and frankly I wondered at the time if that restriction was actually necessary at the time. However, it also wasn't in the way, so there was no need to challenge the assumption. There were also very strong concerns about CSS as a whole being implementable at the time. No browser had yet shipped a confomant implementation of CSS1, and rembember, we were working on ~100MHz 486 processors. The consensus within Netscape at the time was that CSS1 selector matching could *never* be made performant, so anything that impacted performance in CSS was treated with extreme suspicion. We obviously proved that consensus as wrong at the time. And since then we have also proved other 'performance killing' features like `:has()` turned out to be doable after all.

I strongly believe that lookahead will prove viable, and the work done on [#7961](https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1396112293) has identified several optimizations, making it even more likely.

My threat of a Formal Objection stems from the current desire to adopt and ship the compromise solution, without having properly explored and ruled out the optimal solution. I feel this would be a mistake and is not an example of the WG using the proper process to find the ideal solution.

So yes, if we try to finalize on option 3 as it stands, before knowing if the lookahead solution is actually possible or not, I will file an FO.

Secondly, I have issues with option 3 as currently defined, specifically the feature where prefixes to nested rules are optional if the rule doesn't start with an identifier or function.

If the lookahad approach proves viable, these issues are moot.

I have two technical resasons to object to that feature:

1) It is an author foot-gun. The intent of the feature is to allow author to copy/paste rules into nested context without modification. However, authors will have to carefully review those rules for those needing modification, by either a prefix or adding an otherwise unnecessary pseudo-class (which by any definition is a hack). I believe this feature causes more harm than good for this reason alone. Backing up that opinion, we have poll data from authors stating that over 50% of them *will not use this feature*. This is not an author-friendly feature and violates the proprity of constituencies.

2) It narrows the scope of possible future extensions to the CSS language. I'm well aware that some people think the narrowed scope is less of a problem than I do, but regardless, it is something that needs to be taken into account. I do not believe we have done so properly. Furthermore, given the limited utility of the feature, I feel benefit is too small to justify the cost.

I also have a process reason to object. The path to getting us where we are has been to narrow down a broad set of possible solutions. I believe that each decision along that path was made in good faith and with good intentions, however, not every one of those decisions was made with a complete understanding of the big picture. Specifically, the language restrictions were not made clear to many of the WG particiapants until very late in the process, and were not part of any of the public polls. Also, many approaches were ruled out based on opinions, without having fully explored the alternatives, so many of these decisions were made with incomplete information.

Furthemore, the last two times we made major desicions about nesting, *it wasn't on the agenda*. Adding last-minute discussions is fine, but it's not a good way to make major decisions. People did not have time to properly review information, and we have no idea how many people weren't present because they simply didn't know we were going to discuss this. For example, I looked at the agendas and almost didn't attend either meeting.

To this end, should lookahead prove to not be viable, I feel it is necessary to revisit the alternative approaches, taking the larger picture into account, and see if one of them isn't a better solution overall. I have heard too many times, "we already ruled that out" as an excuse to close down discussions that should have been had.

So, yes, if lookahead proves to not be viable, and the WG resolves to ship the current syntax as-is, without re-opening discussions on alternatives presenting all the possible options with a list of all of their costs and benefits, I will file an FO.

Given these explanations, I hope it's obvious that my threat of an FO isn't "stop energy" or me simply trying to bully the group into accepting my preferred solution because I dislike where we are. I genuinely feel that our normal process and work mode has broken down and we need to take a breath and reassess.

There are several paths forward that will not result in me filing an FO.

1) We simply wait a few weeks and get real-world data about the feasability of adding lookahead. Should it prove viable, we're done (modulo the orthogonal issues which I hope we can resolve in the meanwhile). This is my preferred approach.

2) Should the timeframe to evaluate lookahead prove to take "too long" (with some justification of what that means), we can ship a limited version of nesting without the contentious feature. To this end there have been a few proposals (note that the last two these are compatibe with being morphed into other approaches making the prefix optional):

 a) Require a `&` somewhere in the selector. I feel this is a non-starter because it requires lookahead.

 b) Require a `&` prefix on all nested rules and no other use of `&` within the rule. I'm not thrilled about this, but it woulnd't trigger an FO on my part. It can be fixed later if needed.

 c) Require some other prefix, like `@nest` or simply `@`. This would be my preferred interim approach as the prefix can be made optional if lookahead ships later, and avoids the other issues if not. I really don't see `@ div` as any worse than `& div`.

3) Should lookahead prove non-vaible, we reasses and make a proper consensus decision, reevaluating alternative approaches. If we do this, and everyone acts in good faith, and we still come back to the current version of option 3, I will not file an FO.


So I'm adding an Angeda+ label and request we take up the following on a near-term call:

1) Recind the resolution made on [January 11](https://log.csswg.org/irc.w3.org/css/2023-01-11/#e1523515). I argued against that resolution at the time and still believe it serves no purpose other than to act as fuel for bad-faith arguments and shenanigans like [this](https://groups.google.com/a/chromium.org/g/blink-dev/c/eFCrkiLynfU/m/JLsh3zQuAAAJ).

2) Resolve to wait for real data about the viability of lookahead before making decisions to adopt a compromise syntax.


I also want to make clear that the TAG has begun a [review of Nesting](https://github.com/w3ctag/design-reviews/issues/791). The TAG has had discussions, but due to scheduling constraints have not yet had a quorum to make a consensus decision. However, all of the TAG members who have discussed this so far are in agreement that the best path forward is to explore lookahead. There also has been no dissent on the viewpoint that the current approach is an author foot-gun and some kind of mandatory prefix, or alternative scope for nested rules, would be a superior approach for authors.

So in addition to my FO, be aware that it's likely the TAG will not have a favorable review of the design as it stands.


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


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

Received on Sunday, 22 January 2023 02:11:53 UTC