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

@plinss 
> We remove the lookahead restrictions on the parser and 'simply' adopt the SASS syntax. The lookahead restriction came about 25 years ago when there were real concerns that CSS would be too slow to ever implement in a browser and everything was focused on performance. I'd like to see some experimentation and real-world data to check that assumption and see if advancements in processor speed and RAM availability allow us to relax that.

I agree and I have opened an issue about this here with an algorithm that would minimize the performance hit: #7961 
Here is a summary:
- **Gecko:** @emilio [said it could be a viable path forwards for Gecko](https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1292593144) but obviously more research is needed. 
- **Blink:** @sesse was very negative about experimenting in Blink and [shut down the discussion](https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1292694264). 
- **WebKit:** I [contacted the WebKit implementer](https://twitter.com/LeaVerou/status/1585393527152070657), who referred me to the comments by the Blink implementors, as WebKit's CSS parser is basically the same. My understanding is that there was no further personal investigation by the WebKit team.

Sadly the issue was later derailed a bit by those who think `&` should be mandatory.  
One real issue that came out of it was ([raised by @lilles](https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1293206235)) that we'd have to make `{}` invalid in custom properties for that to work, and [there is some limited usage of that in the wild (<0.01%)](https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1294985119), so it's a tradeoff. (IMO still a worthy one).

@jensimmons 
> Implementation experience is the only path forward to find out whether or not if this is a viable alternative. The teams currently implementing CSS Nesting need to try it, test performance, and see what happens. To attempt to figure out a way to make it fast. If so — fantastic, decision made. If not, well, decision made.
> I know folks are already working to see such implementation experience happen. 

 See above, when I tried to discuss it in #7961, [the Google implementor was very negative](https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1293823165):

> I don't share this goal; I would like us to just get the syntax (any syntax) specified, out the door and be done with it. So no, I won't be spending resources trying to bend our minds around how we tokenize CSS to this avail; I can NAK what is a non-starter for us, and that's what you'll get.

Great to hear things have changed since then and folks are working on it. Is it the same folks? Which folks are working on it?


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


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

Received on Thursday, 22 December 2022 11:41:42 UTC