Fix false positives for WebExtension replacement keywords in value-keyword-case

[fregante]

Clearly describe the bug

Chrome/Firefox extensions have CSS keywords that are replaced at runtime and are case-sensitive. For example:

body {
	direction: __MSG_@@bidi_dir__;
}

Which the browser interprets as:

body {
	direction: ltr;
	/* or direction: rtl; */
}

These are mostly used for localization/internalization. Documentation: https://developer.chrome.com/extensions/i18n

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

value-keyword-case

What stylelint configuration is needed to reproduce the bug?

{
  "rules": {
    "value-keyword-case": "lower"
  }
}

Which version of stylelint are you using?

13.3.2

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

CLI

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

Kinda. However it's parsed by the browsers, not a transpiler.

What did you expect to happen?

Keywords that match /__MSG_[^\s]+__/ should be skipped by the rule.

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

test.css
 2:13  ✖  Expected "__MSG_@@bidi_dir__" to be "__msg_@@bidi_dir__"   value-keyword-case

[fregante]

NB: the lower case version is not compatible with browsers.

[jeddy3]

@fregante Thanks for the clear report and for using the template.

I can reproduce this using the demo.

Keywords that match /__MSG_[^\s]+__/ should be skipped by the rule.

Sounds good. It can be added to the isStandardSyntaxValue util (and tests).

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.

[mattxwang]

Is anybody else working on this? If not, I can give it a shot!

[jeddy3]

I can give it a shot!

Excellent. I'll label as "wip" for you.