-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve compatibility with compound selectors #126
base: master
Are you sure you want to change the base?
Conversation
Thanks @siilike! Sorry for putting this off for so long. It would be good to have some review comments to describe the decisions and improvements but I understand it's been so long since you first implemented this. It's great to see all of the new tests and existing tests still passing! I'll need to give this a slightly better look before merge. |
@@ -1,3 +1,5 @@ | |||
var log = require('debug')('postcss-css-variables:is-under-scope'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 on debug
@@ -28,7 +29,8 @@ | |||
"eslint-plugin-react": "^7.1.0", | |||
"mocha": "^5.2.0", | |||
"postcss-discard-comments": "^4.0.0", | |||
"postcss-normalize-whitespace": "^4.0.0" | |||
"postcss-normalize-whitespace": "^4.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't look like postcss-normalize-whitespace
is used anywhere. Let's remove if not needed
I assume you tried this out for the test comparison?
I actually have to admit that I'm not using this plugin any more due to being able to drop IE11 support. It was used in production and I cannot really remember any issues. As it's been so long since I made the changes I know exactly as much as you on how and why they were made. : ) |
@@ -9,16 +12,91 @@ var shallowCloneNode = require('./shallow-clone-node'); | |||
var findNodeAncestorWithSelector = require('./find-node-ancestor-with-selector'); | |||
var cloneSpliceParentOntoNodeWhen = require('./clone-splice-parent-onto-node-when'); | |||
|
|||
var parser = require('postcss-selector-parser'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic! I started trying to use this in https://github.com/MadLittleMods/postcss-selector-scope-utility to replace all of the logic here but never got it over the line.
} | ||
|
||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add a comment describing how compatible
and compatible2
are different and when you should use either
if(b < idx) { | ||
// no match: already compatible or wildcard | ||
if(i === 0) { | ||
state = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can these states be nice string label constants or symbols? Reasoning about these arbitrary state numbers seems mind bending 🤯
// Remove the pseudo selectors from the nodeScope so it can match a broader version | ||
// ex. `.foo:hover` can resolve variables from `.foo` | ||
nodeScopeList = stripPseudoSelectorsFromScopeList(nodeScopeList); | ||
var isUnderScope = function(nodeScopeList, scopeNodeScopeList, /*optional*/ignorePseudo, /*optional*/keepPseudo) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we document this dichotomy between ignorePseudo
and keepPseudo
? I'm not quite wrapping my head around why we need both options and them being opposite default states. Seems like they should both be ignoreX
or keepX
and maybe need better descriptors.
For example, just from an initial look, seems like ignorePseudo
can cover keepPseudo
by being ignorePseudo=false
. But I understand they are probably tackling different use cases. So the parameter name should probably be different.
// Make sure the variable declaration came from the right spot | ||
// And if the current matching variable is already important, a new one to replace it has to be important | ||
var isRoot = varDeclMapItem.parent.type === 'root' || varDeclMapItem.parent.selectors[0] === ':root'; | ||
var process = (ignorePseudo, ignorePseudo2) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks related to my comments about ignorePseudo
/keepPseudo
above, https://github.com/MadLittleMods/postcss-css-variables/pull/126/files#r608857080
We should comment about why 2?
Below, I see we do some matrix processing around these 2 options, would be good to comment about why and the combinations.
|
||
#foo li { | ||
--color: #000000; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 On writing a test case that should NOT happen!
#foo a li { | ||
color: #ffffff; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this rule is missing from the expected output:
#foo.bar a + li {
color: #000000;
}
- In an ideal world, should this be in the output? (is my thinking around this selector correct?)
- Is this one of the known limitations? That's fine, but let's add a comment about it
color: var(--color2); | ||
} | ||
|
||
#bar.bar a c b c + d e { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this isn't in the output because #bar.bar a c b c
does not match #bar a b
and the sibling is off as well.
Let's add a comment above this case about why it does not match and we should not see it in the output.
|
||
#bar li { | ||
color: var(--color2); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the #foo
, #bar
, and #baz
cases can be split into separate tests without affecting what we're trying to test. And makes them easier to understand when they fail.
--color: #aaaaaa; | ||
} | ||
|
||
/* no selector created */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's improve this comment.
/* no selector created because it's targeting `a` and the rule with the color declaration is targeting `li` */
|
||
#foo1.bar ul div > li { | ||
--color: #777777; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add a comment about why this rule should NOT match
|
||
#foo1.bar ul > div li { | ||
--color: #888888; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going back and forth on whether this should match 🤔
From:
#foo1 ul > li
Matches:
#foo1.bar ul > li
Should this match?:
#foo1.bar ul > div li
In any case, a comment about why or known-limitation
|
||
#foo3 ul + li { | ||
color: var(--color); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think all of the #foo1
, #foo2
, and #foo3
rules can be split into their own tests
|
||
body.bar *:hover { | ||
--color: #111111; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This rule looks like a known-limitation and should be in the output. Let's add a comment
|
||
#foo.bar li { | ||
--color: #000000; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a known-limitation that should be in the output. Let's add a comment.
(maybe)
Or why it shouldn't be in output
@@ -2,6 +2,10 @@ | |||
color: #ff0000; | |||
} | |||
|
|||
.bar:hover + .foo { | |||
color: #f0f000; | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Happy to see this fixed now
@@ -1,11 +1,11 @@ | |||
var isUnderScope = require('./is-under-scope'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually have to admit that I'm not using this plugin any more due to being able to drop IE11 support.
It was used in production and I cannot really remember any issues.
As it's been so long since I made the changes I know exactly as much as you on how and why they were made. : )
@siilike No worries, I understand. I might just add the comments to the tests where I pointed it out and merge this.
Seems like a decent improvement regardless of the code and us trying to understand it better.
Can this be merged? |
Fix #125
Fix #77
Fix #46
Fix #41
It's not perfect, but should be a significant improvement.
Also added special syntax for cases where explicit relations are not defined:
which would output: