Re: [csswg-drafts] [selectors4] Name the “functional pseudo-class like :matches() with 0 specificity”

So since when has short lived vendor implementation ruled what happens to a standard.
I don't get it what's wrong, this is not yet another piece of software that you can throw away in some years and replace it with something else entirely and somehow I got the feeling that that's the recent predominant mind set. /rant.

Without much details to rephrase what @fantasai says:
* If :not() and :matches() are the inverse of each other they should have inversed names for easy understanding and usage.
* If :is() and :not() have inversed semantic meaning, they should behave like that and not unexpectedly do something else.

Logical options that make sure developers in future are not the hell confused about it (and TWBS-hell-soup shows most, /are/):

* A) Rename matches() to is() - use matches() for the new specificity-circumventing feature discussed here
* B) Alias is() and matches() and find a new name for the feature proposed here instead of matches().

So why don't we collect alternate names for the current *matches* proposal and if we can find something really reasonable we can alias is() and matches() and deprecate matches()? What's so wrong about that?

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

Received on Wednesday, 3 January 2018 02:10:42 UTC