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

> An implementation parsing a style declaration will need to presume anything that doesn't start with an identifier or function is a selector, which restricts our ability to ever extend property declarations with anything that doesn't start with an identifier or function. Furthermore this restricts our ability to ever extend the definition of an identifier or a function. As an example, if this were implemented first, we could never have added custom properties with the current syntax (which redefined identifiers).

I don't think this is true. @fantasai explained in https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982 that if something started with a currently unknown symbol (i.e. "doesn't start with an identifier or function") it would be thrown out as a parse error. 

So starting something with a question mark, for example, would be thrown out as neither a declaration nor a selector. But that doesn't preclude us from using a question mark in the future as the start of a property or modifier of a property. Nor from using it in the future as the start or part of a selector. Just that if we decided to use a question mark as part of property declarations (occurring at the beginning of the property), then we wouldn't be able to later start a selector or relative selector with that question mark (unless, say, one required a space after it and the other didn't, in which case a question mark could still start both). At least that's my understanding. 

I do agree that a bare @ would be a better alternative to wrapping a tag name selector in `is()`. But that can be a separate future enhancement, and doesn't need to be part of the current proposal. 



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


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

Received on Sunday, 15 January 2023 21:04:15 UTC