- From: SelenIT via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Jan 2018 18:02:41 +0000
- To: public-css-archive@w3.org
Well, maybe then we can avoid the confusion if we could use the pattern [proposed in #1170](https://github.com/w3c/csswg-drafts/issues/1170#issuecomment-329877027) by @tabatkins and add an extra optional argument to the existing `:matches()` _instead of_ duplicating its functionality in a new pseudo-class at all? So while `:matches(...)` would behave as it currently does, for example, `:matches(... as 0,0,0)` would have the behavior of the proposed `:is()` (zero-specificity matching), and `:matches(... as 0,1,0)` would match any of its arguments with the specificity of the single class. It would be backwards compatible with the existing `:matches()` implementations and wouldn't introduce any ambiguity in what is the inverse of `:not()`. Moreover, the similar extra argument could be added to `:not()` as well, making the behavior of `:not()` and `:matches()` symmetric. Or is it too late to make such changes in Level 4? -- GitHub Notification of comment by SelenIT Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-354832935 using your GitHub account
Received on Tuesday, 2 January 2018 18:02:44 UTC