Ignore maps and lists in color-named #2182

mmase · 2016-12-09T13:41:47Z

Which issue, if any, is this issue related to?

#2009

Is there anything in the PR that needs further explanation?

No, it's self explanatory.

alexander-akait · 2016-12-09T14:42:33Z

lib/rules/color-named/index.js

@@ -49,7 +50,7 @@ const rule = function (expectation, options) {
    const namedColors = Object.keys(namedColorData)

    root.walkDecls(decl => {
-      if (propertySets.acceptCustomIdents.has(decl.prop)) {
+      if (propertySets.acceptCustomIdents.has(decl.prop) || !isStandardSyntaxDeclaration(decl)) {


use isStandardSyntaxDeclaration we disabled check on color in variables, root and scss nested properties (see https://github.com/stylelint/stylelint/blob/master/lib/utils/isStandardSyntaxDeclaration.js).
@stylelint/core what do you think guys? I vote for the exclusion of non-standard syntax.

@mmase Thank you for the PR.

use isStandardSyntaxDeclaration we disabled check on color in variables, root and scss nested properties

I might have made a mistake suggesting the use of isStandardSyntaxDeclaration to resolve this issue as it's a bit of a sledgehammer. In #2009 we agreed to ignore only maps and lists. This is because we made a design decision a while back to try to be as fine-grained as reasonably possible when ignoring non-standard constructs. This is particularly applicable to rules that check things within values e.g. color-*, number-*, unit-* etc.

@mmase As such we might want to slightly rethink how we go about this. Perhaps the following would work?:

When we check a postcss-value-parser's word, we should first check if it has a parent node and if that parent node is a function, and then check if that function is a standard one using isStandardSyntaxFunction. We'll want to do this inside the walk.

This should ignore maps and lists like this:

colors: (white: #fff);

While not hammering nested props and variables.

Unfortunately, this is tricky first-stylelint-PR as it deals with the way postcss and postcss-value-parser parse non-standard syntax and constructs. Would you be willing to explore implementing this more fine-grained solution?

Makes sense! Will dig in and make some changes

@jeddy3 so far pretty straight forward, but the maps return false for the isStandardSyntaxFunction as maps aren't given a value by postcss-value-parser. Thoughts?

I pushed a commit up with what seems to produce expected results, though sans isStandardSyntaxFunction due to the above.

jeddy3

@mmase Thanks! I think this work well.

@davidtheclark Any thoughts on this approach?

jeddy3 · 2016-12-12T10:49:22Z

lib/rules/color-named/index.js

      valueParser(decl.value).walk(node => {
        const value = node.value,
          type = node.type,
          sourceIndex = node.sourceIndex

+        if (type === "function") {


Could we get a brief comment above this line stating what this is here for as it's not so obvious and I'm sure we'll come back to it in a couple of months time wondering what it does? :)

Yes, we definitely need a clarifying comment here. Also, I think the variable name functionNodes is misleading. You're not actually putting nodes in it, right? Could you please try to name that array to match its contents?

mmase · 2016-12-12T14:16:10Z

Made requested changes, let me know if you have any other thoughts on improvements!

davidtheclark · 2016-12-12T14:33:13Z

lib/rules/color-named/index.js

+        }
+
+        // Return early if node is inside of a function
+        if (functionNodeIndexes.indexOf(sourceIndex) > -1) {


Can we accomplish the same thing in a more standard way with blurFunctionArguments? Have you checked out what is happening in other rules that also ignore function arguments?

Was just about to mention that - as it appears that this is essentially the same behavior as the ignore inside-function option. Which makes me ask, what is #2009 asking of that can't be achieved with that option?

Additionally, it appears returning false inside of a function node is all that needs to be done.

davidtheclark · 2016-12-12T14:38:43Z

@mmase I think the relevant suggestion in #2009 is

Perhaps we should change the behaviour to ignore maps by default, and reserve "ignore": ["inside-function"] for just things like $color-footer: color(white) !default;?

from @jeddy3.

If we can't ignore maps without doing the same thing as "ignore": ["inside-function"], then we should just leave things as they are. If we can ignore them by some other means, we'd do that.

mmase · 2016-12-12T14:49:58Z

Ah right. Apologies, missed that. Okay, will try a few things as this current implementation feels too harsh.

jeddy3 · 2016-12-12T15:02:04Z

Made requested changes, let me know if you have any other thoughts on improvements!

Thank you!

I think this issue has highlighted a few shortcomings in the tests of this rule as it's not immediately obvious from them if this rule is behaving as expected.

I think that the default behaviour should be:

Check color representations inside all standard syntax functions (e.g. when using color-mod: a { color: color(black a(50%)))
Ignore non-standard list and map syntax i.e. (..)

Then we provide an "ignore": ["inside-function"] option for ignoring color representations within standard syntax functions.

I think we're missing at least two tests in the "never" set that show that colours within standard syntax functions should be checked by default e.g. accept and reject tests for a { color: color(black a(50%)).

And another test in the "always-where-possible" reject set. (There is one for the accept set already.)

I think these new reject tests will likely fail with the current implementation in this PR.

If we can ignore them by some other means, we'd do that.

I thought we might be able to use postcss-value-parser to distinguish between standard syntax functions (i.e. those that have a name (e.g. color(..) or map-get(..)) and non-standard syntax ones (i.e. those that don't (..)). @mmase Do you think this might be possible or did your initial investigation turn up a blank?

Thanks for sticking with us on this. Dealing with non-standard syntax is usually deceptively tricky.

mmase · 2016-12-15T02:09:04Z

@jeddy3 Sorry for the delay on this. Declaration values should let us see if they are in a named function or non-standard syntax function (no name). However, I'm wondering if we need to go a step further.

For example, in this case, we should ignore white and grey:

$colors: (
  white: #000,
  grey: #333
);

But, in this case, we should probably still warn:

$colors: (
  white: white,
  grey: grey
);

Do you agree?

davidtheclark · 2016-12-15T12:59:24Z

@mmase Parsing a Sass map is not within the domain of stylelint — rather, a SCSS-specific plugin should take care of that. stylelint itself should just ignore the construction, avoiding mistaken warnings.

mmase · 2016-12-15T13:13:56Z

@davidtheclark fair enough, that makes sense 👍

jeddy3 · 2016-12-15T14:03:58Z

Parsing a Sass map is not within the domain of stylelint — rather, a SCSS-specific plugin should take care of that. stylelint itself should just ignore the construction, avoiding mistaken warnings.

👍

@mmase If you're interested, David goes into a bit more background to this problem space here.

And for some context specific to this instance... dollar-variables are parsed as decls. Nested props are parsed as decls within rules. In both instances, the value part of the declaration is made available within decl.value. This isn't the case with lists and maps, where the decl.value contains the property-value pairs of the map as a single string.

Therefore, it would require additional code within stylelint to parse this non-standard construct.

Which is why the suggestion is to use isStandardSyntaxFunction to ignore list and maps without hammering vars and nested props.

mmase · 2016-12-15T15:24:07Z

@jeddy3 thanks for that. isStandardSyntaxFunction is great for ignoring non-standard list and map syntax i.e. (..). So, that's done and makes sense (I was previously using isStandardSyntaxDeclaration which is incorrect).

However, the remaining issue is ignoring instances of color-mods like color(red) or other function calls myFunction(red). Are we looking to only ignore color-mods?

jeddy3 · 2016-12-15T15:48:23Z

So, that's done and makes sense (I was previously using isStandardSyntaxDeclaration which is incorrect).

👍

However, the remaining issue is ignoring instances of color-mods like color(red) or other function calls myFunction(red). Are we looking to only ignore color-mods?

We're ignoring neither by default. There is already the ignore: ["inside-function"] option that the user can use to opt into this behaviour. (This option will ignore values in standard syntax functions, so that includes functions included in the spec (like color()) and custom functions like myFunction(red).)

It sounds like what you've done so far is what we need. If you've also added those tests, then I think you can push up what you've got and we'll be able to see if it's behaving as expected :)

mmase · 2016-12-15T15:49:22Z

I suppose that could be covered by "ignore": "inside-function"?

mmase · 2016-12-15T15:49:44Z

Ha, just saw you commented the same :) Okay, will write some tests and push up 👍

mmase · 2016-12-15T17:01:43Z

@jeddy3 @davidtheclark made some changes. thanks for your patience with me on this one. I hope this is the solution you are looking for!

alexander-akait · 2016-12-15T17:28:18Z

lib/rules/color-named/index.js

@@ -70,6 +71,10 @@ const rule = function (expectation, options) {
          return false
        }

+        if (!isStandardSyntaxFunction(node)) {
+          return false


Better use just return

This doesn't appear to work. I don't know a ton about postcss-value-parser, but returning undefined on only a value would work. However, since we are making an assertion on a node, you need to return false for it to skip the values within that node. Otherwise, I would group it with the isStandardSyntaxValue check below this.

jeddy3

Looking good! I've a request for one last test at line 266...

{
    code: "a { color: color(#000 a(50%)) }",
    message: messages.expected("black", "#000"),
    line: 1,
    column: 12,
  } ],

To make sure that we're checking inside of functions for the "always-where-possible" option.

jeddy3 · 2016-12-15T17:24:26Z

lib/rules/color-named/__tests__/index.js

@@ -56,6 +56,9 @@ testRule(rule, {
  }, {
    code: "a { font: 10px/14px Brown, sans-serif; }",
    description: "ignore font family names that are colors",
+  }, {
+    code: "colors: (white: #fff, blue: #00f);",


Let's use $colors here to make it extra clear this is a non-standard.

jeddy3 · 2016-12-15T17:49:33Z

@mmase Ooops, code for my test should be a { color: color(#000 a(50%)) }... I accidently left out the property name.

mmase · 2016-12-15T17:56:49Z

@jeddy3 ah, yeah I did the same thing a few times as well. all set

jeddy3

Excellent. LGTM :)

mmase · 2016-12-17T14:49:13Z

thanks guys!

davidtheclark · 2016-12-17T17:33:15Z

Changelog entry:

Fixed: color-named now ignores SCSS maps, so map property names can be color names (#2182)

mmase force-pushed the color-named branch from 365bc75 to 5a56158 Compare December 9, 2016 13:42

alexander-akait reviewed Dec 9, 2016

View reviewed changes

alexander-akait added non-standard syntax status: needs discussion triage needs further discussion labels Dec 9, 2016

jeddy3 changed the title ~~Proposal: Ignore color-named rule in non-standard syntax~~ Ignore maps and lists in color-named Dec 10, 2016

jeddy3 added PR: needs revision and removed non-standard syntax status: needs discussion triage needs further discussion labels Dec 10, 2016

mmase force-pushed the color-named branch 2 times, most recently from d7567e2 to a676271 Compare December 12, 2016 05:35

jeddy3 added PR: review needed and removed PR: needs revision labels Dec 12, 2016

jeddy3 requested changes Dec 12, 2016

View reviewed changes

mmase force-pushed the color-named branch from a676271 to a25e093 Compare December 12, 2016 14:15

davidtheclark reviewed Dec 12, 2016

View reviewed changes

jeddy3 added PR: needs revision and removed PR: review needed labels Dec 12, 2016

mmase force-pushed the color-named branch 4 times, most recently from db78ca6 to 80c36d9 Compare December 15, 2016 16:48

jeddy3 added PR: review needed and removed PR: needs revision labels Dec 15, 2016

alexander-akait suggested changes Dec 15, 2016

View reviewed changes

jeddy3 requested changes Dec 15, 2016

View reviewed changes

mmase force-pushed the color-named branch from 80c36d9 to 8e39e84 Compare December 15, 2016 17:43

mmase force-pushed the color-named branch from 8e39e84 to 0375fb0 Compare December 15, 2016 17:57

Ignore maps and lists in color-named

b67ced8

mmase force-pushed the color-named branch from 0375fb0 to b67ced8 Compare December 15, 2016 18:07

alexander-akait approved these changes Dec 15, 2016

View reviewed changes

jeddy3 approved these changes Dec 15, 2016

View reviewed changes

davidtheclark added PR: review accepted and removed PR: review needed labels Dec 17, 2016

davidtheclark approved these changes Dec 17, 2016

View reviewed changes

davidtheclark merged commit 5c38334 into stylelint:master Dec 17, 2016

davidtheclark mentioned this pull request Dec 17, 2016

False positives with SCSS maps in color-named #2009

Closed

sergesemashko pushed a commit to sergesemashko/stylelint that referenced this pull request Mar 3, 2017

Ignore maps and lists in color-named (stylelint#2182)

5d13347

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ignore maps and lists in color-named #2182

Ignore maps and lists in color-named #2182

mmase commented Dec 9, 2016

alexander-akait Dec 9, 2016

jeddy3 Dec 10, 2016

mmase Dec 10, 2016

mmase Dec 12, 2016

mmase Dec 12, 2016

jeddy3 left a comment

jeddy3 Dec 12, 2016 •

edited

davidtheclark Dec 12, 2016

mmase commented Dec 12, 2016

davidtheclark Dec 12, 2016

mmase Dec 12, 2016

mmase Dec 12, 2016

davidtheclark commented Dec 12, 2016

mmase commented Dec 12, 2016

jeddy3 commented Dec 12, 2016 •

edited

mmase commented Dec 15, 2016

davidtheclark commented Dec 15, 2016

mmase commented Dec 15, 2016

jeddy3 commented Dec 15, 2016

mmase commented Dec 15, 2016 •

edited

jeddy3 commented Dec 15, 2016

mmase commented Dec 15, 2016 •

edited

mmase commented Dec 15, 2016

mmase commented Dec 15, 2016

alexander-akait Dec 15, 2016

mmase Dec 15, 2016 •

edited

jeddy3 left a comment •

edited

jeddy3 Dec 15, 2016

jeddy3 commented Dec 15, 2016 •

edited

mmase commented Dec 15, 2016 •

edited

jeddy3 left a comment

mmase commented Dec 17, 2016

davidtheclark commented Dec 17, 2016

Ignore maps and lists in color-named #2182

Ignore maps and lists in color-named #2182

Conversation

mmase commented Dec 9, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeddy3 left a comment

Choose a reason for hiding this comment

jeddy3 Dec 12, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mmase commented Dec 12, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidtheclark commented Dec 12, 2016

mmase commented Dec 12, 2016

jeddy3 commented Dec 12, 2016 • edited

mmase commented Dec 15, 2016

davidtheclark commented Dec 15, 2016

mmase commented Dec 15, 2016

jeddy3 commented Dec 15, 2016

mmase commented Dec 15, 2016 • edited

jeddy3 commented Dec 15, 2016

mmase commented Dec 15, 2016 • edited

mmase commented Dec 15, 2016

mmase commented Dec 15, 2016

Choose a reason for hiding this comment

mmase Dec 15, 2016 • edited

Choose a reason for hiding this comment

jeddy3 left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeddy3 commented Dec 15, 2016 • edited

mmase commented Dec 15, 2016 • edited

jeddy3 left a comment

Choose a reason for hiding this comment

mmase commented Dec 17, 2016

davidtheclark commented Dec 17, 2016

jeddy3 Dec 12, 2016 •

edited

jeddy3 commented Dec 12, 2016 •

edited

mmase commented Dec 15, 2016 •

edited

mmase commented Dec 15, 2016 •

edited

mmase Dec 15, 2016 •

edited

jeddy3 left a comment •

edited

jeddy3 commented Dec 15, 2016 •

edited

mmase commented Dec 15, 2016 •

edited