- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Jan 2023 22:49:55 +0000
- To: public-css-archive@w3.org
> One of the claims I have heard is that we can ship option 3 now, then in a lookahead future we can update nesting syntax. Could someone elaborate on what that update would look like? For authors, the update looks like "you don't need to worry about selectors starting with an ident anymore, it Just Works™ (but if you were already doing `:is(div).foo` that's still fine)". For implementations, we're working thru what the parsing algo would look like in https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1396112293 > I think you may be referring to the point I made: that if we know infinite lookahead is coming, I'd rather ship a syntax with a mandatory &, so that it becomes optional for descendants and combinators at once. Note that I'm only proposing this for user experience, it does not solve the lookahead issue to have a mandatory &. I'm strongly against a "mandatory &" - nothing is helped by requiring an & *somewhere*. (That is, `div > &` satisfies this but is still problematic in such a world, while `> div` has no problems but is mysteriously disallowed by such a restriction.) I don't understand where this suggestion is coming from or in what way it would help us. > and only allow the nesting forms that begin with & until we determine whether lookahead is possible. This is also overly restrictive. Again, if we determine infinite lookahead is possible, then `div + &` is fine. If we determine that it's *not* possible, then the WG *has already spent months talking over all the options*, and decided the current spec is the most preferable way forward. The *only* reason it would make sense to impose such a restriction is we think that, when we determine that lookahead is infeasible, we'll scrap all the preceding resolutions and re-evaluate the entire issue fresh. But we're not going to! All of the discussions we've already had were made *under the assumption that infinite lookahead wasn't possible*, so if we decide that it is, indeed, not possible, we'll just be affirming that the preceding discussions were assuming correctly. The *only* effect that our investigation into infinite lookahead can have is proving that is *is* possible, and causing us to switch over to a parsing method with the new assumptions. Otherwise, our current situation is *unchanged*, and we should stick our current resolutions. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1397712644 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 January 2023 22:49:57 UTC