Fix false positives for variables and color functions in `color-function-notation`

Clearly describe the bug

A follow-up from #5638, where the original issue was fixed correctly in my tests but more advanced scenarios still result in false positives, e.g. when using Sass’ color.mix within rgba().

Which rule, if any, is the bug related to?

color-function-notation

What code is needed to reproduce the bug?

@use 'sass:color';

$color: rgba(color.mix(#000, #fff, 35%), 0.6);

What Stylelint configuration is needed to reproduce the bug?

{
  "rules": {
    "color-function-notation": "modern"
  }
}

Which version of Stylelint are you using?

14.0.1 as well as main from commit e2c3473.

How are you running stylelint: CLI, PostCSS plugin, Node.js API?

stylelint \"src/**/*.scss\"

Does the bug relate to non-standard syntax (e.g. SCSS, Less etc.)?

Yes, SCSS color functions

What did you expect to happen?

No errors

What actually happened (e.g. what warnings or errors did you get)?

 25:27  ✖  Expected legacy color-function notation  color-function-notation

[lachieh]

If anyone subbed to this issue is interested, I created a rule proposal about how sass color functions work and how they can potentially be linted to avoid confusion. stylelint-scss/stylelint-scss#582

[jeddy3]

@cascornelissen Thanks for creating the issue.

I think we can improve the heuristics in the isStandardSyntaxColorFunction util to catch this. If we change the logic to look for a word starting with # within any of the nodes within the function (including those nested within other functions).

I don’t believe there’s a situation where this can happen with standard CSS. The closest we can get is:

a { color: rgba(var(--r, 20), var(--g), var(--b), 0.6); }

But the fallback words, e.g. 20, will never be hex colours.

I’ve labelled the issue as ready to implement. Please consider contributing if you have time.

There are steps on how to fix a bug in a rule in the Developer guide.