CSS parser does not properly apply specificity calculations to selectors in the functional part of a pseudo class. #1823

Open
opened 5 months ago by Moonchild · 0 comments
Owner

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.

: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.

http://wpt.live/css/selectors/not-specificity.html
http://wpt.live/css/selectors/invalidation/not-002.html

https://drafts.csswg.org/selectors-4/#specificity-rules

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 and :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.

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`. `: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. http://wpt.live/css/selectors/not-specificity.html http://wpt.live/css/selectors/invalidation/not-002.html https://drafts.csswg.org/selectors-4/#specificity-rules 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` and `: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.
Moonchild added the
Layout - CSS
label 5 months ago
athenian200 was assigned by Moonchild 5 months ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MoonchildProductions/UXP#1823
Loading…
There is no content yet.