Menu ▾ ▴

#87 CSS3 parsing of :not(X) , :nth-child(X) arguments incomplete

0.9.28
open
nobody
None
1
2019-06-30
2019-06-29
Jeremie Miserez
No

Parsing ":not(FOO)" or ":nth-child(FOO)" results in a PseudoClassConditionImpl with value "not(FOO)" or "nth-child(FOO)", i.e. the argument itself is not parsed any further. This is in SACParserCSS3.

This makes it impossible to differentiate between ":not(#foo)" and ":not(.foo)" without putting the argument string through second parser, i.e. the tree is incomplete. I found this issue when calculating CSS selector specificity using the the current parsers: ":not(#foo)" and ":not(.foo)" return the same single SAC_PSEUDO_CLASS_CONDITION/PseudoClassConditionImpl, although their specifity is different (1-0-0 vs 0-1-0) and there could be more selectors inside.

I guess the issue only is that CSS3 parsing/grammar is incomplete. I'll see if I can attach a patch, but it may take a while.

See here for more:
- https://www.w3.org/TR/selectors-3/#negation
- https://www.w3.org/TR/selectors-3/#nth-child-pseudo

Discussion

  • Jeremie Miserez

    Jeremie Miserez - 2019-06-30
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,9 +1,9 @@
-Parsing ":not(FOO)" results in a PseudoClassElementImpl with value "not(FOO)", i.e. the argument itself is not parsed any further. This is both in SACParserCSS21 and SACParserCSS3.
+Parsing ":not(FOO)" or ":nth-child(FOO)" results in a PseudoClassConditionImpl with value "not(FOO)" or "nth-child(FOO)", i.e. the argument itself is not parsed any further. This is in SACParserCSS3.

-This makes it impossible to differentiate between ":not(#foo)" and ":not(.foo)" without putting the argument string through second parser, i.e. the tree is incomplete.
+This makes it impossible to differentiate between ":not(#foo)" and ":not(.foo)" without putting the argument string through second parser, i.e. the tree is incomplete. I found this issue when calculating CSS selector specificity using the the current parsers: ":not(#foo)" and ":not(.foo)" return the same single SAC_PSEUDO_CLASS_CONDITION/PseudoClassConditionImpl, although their specifity is different (1-0-0 vs 0-1-0) and there could be more selectors inside.

-I found this issue when calculating CSS selector specificity using the the current parsers: ":not(#foo)" and ":not(.foo)" return the same single SAC_PSEUDO_CLASS_CONDITION/PseudoClassElementImpl, although their specifity is different (1-0-0 vs 0-1-0) and there could be more selectors inside.
+I guess the issue only is that CSS3 parsing/grammar is incomplete. I'll see if I can attach a patch, but it may take a while.

-See here for more about the negation pseudo-class: https://www.w3.org/TR/selectors-3/#negation
-
-This isn't critical, but the parser is still incorrect.
+See here for more:
+- https://www.w3.org/TR/selectors-3/#negation
+- https://www.w3.org/TR/selectors-3/#nth-child-pseudo
     

  • Jeremie Miserez

    Jeremie Miserez - 2019-06-30
    • summary: Parsing of :not(X) argument incomplete --> CSS3 parsing of :not(X) , :nth-child(X) arguments incomplete
     

  • Jeremie Miserez

    Jeremie Miserez - 2019-06-30

    Updated the issue to better describe the problem.

     

Anonymous
Anonymous

Add attachments
Cancel





Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.