- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Apr 2023 01:07:41 +0000
- To: public-css-archive@w3.org
> My impression is that we have discussed error recovery issues If that's the consensus, then so be it, I'll stop complaining, but before we get there, let me point to evidence that error recovery at least hasn't been fully considered in past decisions. See in this thread alone: @FremyCompany asking for examples of the error recovery problem (indicating he's not intrinsically familiar with the issue), yet expresses a strong bias against at-rules; Tab (who I know fully understands the issue), and myself both still getting error recover behavior wrong during conversations; several people expressing surprise during relatively recent calls about the error recovery and syntax restriction issues (well after at-rules were rejected). My argument is that sufficient evidence exists that all the factors weren't taken into account during previous decisions to warrant at least a 5-minute overview of the relative costs and benefits of the two approaches and a simple sanity-check resolution, confirming we all know what we're buying into. Once again, I'm not advocating against adopting the look-ahead behavior, I just want us to do it with our eyes open and decisions made properly. If the choice were simply a mandatory `@nest` prefix or not, with no other issues or consequences, I wouldn't even be raising this, of course we wouldn't require the prefix. But the choice is between look-ahead, which has other costs and issues, and `@nest` that's slightly more verbose, but has no other issues. -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1501266054 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 April 2023 01:07:42 UTC