CSS parser does not properly apply specificity calculations to selectors in the functional part of a pseudo class.
Cloned from GRE#3033 @athenian200
I discovered this issue while working on WebComponents, and I've discovered that we seem to have a problem that goes a bit deeper.
I've been able to confirm this is a problem for us even with pseudo classes that we already support, such as
:not is a very good example, because we already have this so we can rule out the new implementation woes. It's also an instance where although it is itself not included in specificity calculations as a pseudo class, the selectors it uses inside a functional part do have specificity that must be accounted for.
As you can see, we fail almost every test here except for the first in each case, and they all seem to be testing the weight of specificity rules inside selectors used with pseudo classes. So basically the problem is that the selectors contained within a functional part of a pseudo class do not affect specificity, as far as I can tell. At first I thought it was just that we didn't make the specificity of a pseudo-class with a selector in its functional part higher than a pseudo-class without a functional part, but it turns out we just aren't giving selectors their proper weight in specificity calculations for the most part, even in instances when they all have a selector.
So, I'm documenting this here because it's something I will have to deal with sooner or later. The good news is that if I can get this implemented, it should fix
:not as well as
:host-context. So the problem isn't with how those pseudo-classes are implemented, the problem is that the thing they are implemented into is apparently not aligned with the current CSS specification, and the problem isn't limited to WebComponents but is spilling over into other things.
Deleting a branch is permanent. It CANNOT be undone. Continue?