add handling for :matches and :is

[joyously]

:any and :matches and :is need selector lists to test support, so the additional call was added.
:is is a special case since the standard renamed it, so it gets its own if statement.

For part of #6130

[LeaVerou]

Thanks for submitting a PR!

If I'm understanding this correctly, it seems to be special casing a specific selector in code that is supposed to handle selectors generically. I'm not very comfortable with that, once we start handling exceptions like this, the code will progressively get messier and messier. If you can think of a more general way to handle this that will also work for other cases (now or in the future), I'd be glad to merge it, but this doesn't scale.

[joyously]

There are two things: one is that the original code used a generic selector {} to test support, and that will never work for :any, :matches, :is because they take parameters. So checking with another generic selector(a,p) {} is needed.
The other is the special case of a selector that got renamed, but the prefixes did not. The :is selector could be left out if you don't want the special handling, but it's not as if there are a huge number of selectors, so scaling isn't really that big of a deal. I suppose they could rename more in the future, but having a fix now shouldn't be dependent on some unknown future, should it? Do you have any suggestions for how else to do a simple if statement?

[LeaVerou]

one is that the original code used a generic selector {} to test support, and that will never work for :any, :matches, :is because they take parameters. So checking with another generic selector(a,p) {} is needed.

Correct. Although it's impossible to know what parameters to test with when it comes to parameterized selectors, so this probably needs to be part of the selector definition (just like with values we tell PF which property to test them with).

but it's not as if there are a huge number of selectors, so scaling isn't really that big of a deal. I suppose they could rename more in the future, but having a fix now shouldn't be dependent on some unknown future, should it?

Famous last words :) While there's certainly always a danger of potential futures blocking current development, some planning ahead is good. We rename (early) things all the time, it can easily happen again. Also, we don't tend to add stuff to PF with no implementations, and AFAIK :is has no implementations yet (feel free to correct me if that's not the case, I'd be delighted!)

[joyously]

Although it's impossible to know what parameters to test with when it comes to parameterized selectors, so this probably needs to be part of the selector definition (just like with values we tell PF which property to test them with).

In this case, if it's part of the definition, the prefix would be wrong. I would have to define another object to hold the test definition and some way of when to use it. But as of now, the only selectors that take parameters take the same parameters, so I used the shortest, smallest method to test them.

I'll remove the :is.
I guess by the time a browser supports :is, we can find some other way to do it since you can't have two with the same "name".

[LeaVerou]

In this case, if it's part of the definition, the prefix would be wrong. I would have to define another object to hold the test definition and some way of when to use it.

I don't understand what you mean here. Could you elaborate?

But as of now, the only selectors that take parameters take the same parameters, so I used the shortest, smallest method to test them.

That's not true, e.g. :nth-child() or :dir() accept different kinds of arguments. They don't need prefixing though. But assuming all parameterized selectors that may ever need prefixing have selector arguments is a bit fragile.