Recent changes to 87: CSS3 parsing of :not(X) , :nth-child(X) arguments incomplete

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

2019-06-30T05:37:22.294000Z

Updated the issue to better describe the problem.

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

2019-06-30T05:36:10.772000Z

summary: Parsing of :not(X) argument incomplete --> CSS3 parsing of :not(X) , :nth-child(X) arguments incomplete

#87 Parsing of :not(X) argument incomplete

2019-06-30T05:35:38.816000Z

Description has changed:

Diff:

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

-This makes it impossible to differentiate between &#34;:not(#foo)&#34; and &#34;:not(.foo)&#34; without putting the argument string through second parser, i.e. the tree is incomplete.
+This makes it impossible to differentiate between &#34;:not(#foo)&#34; and &#34;:not(.foo)&#34; 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: &#34;:not(#foo)&#34; and &#34;:not(.foo)&#34; 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: &#34;:not(#foo)&#34; and &#34;:not(.foo)&#34; 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&#39;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&#39;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

Parsing of :not(X) argument incomplete

2019-06-29T11:17:44.158000Z

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.

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/PseudoClassElementImpl, although their specifity is different (1-0-0 vs 0-1-0) and there could be more selectors inside.

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.

Parsing of :not(X) argument incomplete

2019-06-29T11:17:44.158000Z

Ticket 87 has been modified: Parsing of :not(X) argument incomplete
Edited By: Jeremie Miserez (jmiserez)
Description updated:
--- description-old

+++ description-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

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

2019-06-29T11:17:44.158000Z

Ticket 87 has been modified: CSS3 parsing of :not(X) , :nth-child(X) arguments incomplete
Edited By: Jeremie Miserez (jmiserez)
Summary updated: u'Parsing of :not(X) argument incomplete' => u'CSS3 parsing of :not(X) , :nth-child(X) arguments incomplete'