no-unsupported-browser-features should have option to not fail if vendor-prefixed version available

[villesau]

no-unsupported-browser-features -rule errors currently when using latest 2 chrome versions and 'appearance' -property. Anyhow we use Autoprefixer which prefixes that to '-webkit-appearance' which is supported by chrome. Thus would be really good to have option to allow non-supported properties if it has vendor-prefixed version available.

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

no-unsupported-browser-features

What CSS is needed to reproduce this issue?

.my-class {
appearance: none;
}

What stylelint configuration is needed to reproduce this issue?

{
  "rules": {
    "no-unsupported-browser-features": [true, {"browsers": "last 2 Chrome versions"}],
    "property-no-vendor-prefix": true
  }
}

expected config(as example):

{
  "rules": {
    "no-unsupported-browser-features": [true, {"browsers": "last 2 Chrome versions", "autoprefixer/allow-if-vendor-version-available": true}],
    "property-no-vendor-prefix": true
  }
}

Which version of stylelint are you using?

7.7.0

Does your issue relate to non-standard syntax (e.g. SCSS, nesting, etc.)?

Related to vendor-prefixes and autoprefixer which should fix those.

What did you expect to happen?

i expected to have config to allow unsupported properties if vendor-specific version of that is available. Thus check should not fail.

[jeddy3]

@villesau Thank you for the suggestion and for using the issue template.

I think this is connected to doiuse, the library that this rule wraps. @stylelint/core I think this issue is a good catalyst to discuss the group of rules that wrap 3rd party linters from #2079:

• no-browser-hacks -> wraps stylehacks
• no-indistinguishable-colors -> wraps colorguard
• no-unsupported-browser-features -> wraps doiuse

Are we expected to create wrapper within core for every PostCSS-based linting tool that gets created? I think having the logic of every core rule owned by the stylelint org is a criteria worth adding.

I think these three rules should be plugins. Perhaps owned by the original tool authors (who might find having access stylelint features like severity levels, disable comments etc useful)

I think no-unsupported-browser-features has an ambiguous finished state (as this issue highlights).

I believe no-browser-hacks and no-unsupported-browser-features trip up (rather than ignore) non-standard syntax.

I think no-indistinguishable-colors suffers from the same issues outlined in #2220 (comment) i.e. it only checks for indistinguishable colors within a source, which isn't very helpful for ensuring a consistent colour palette across a whole site.

Thoughts?

[alexander-akait]

@jeddy3 agree, all these rules should be plugins.

[villesau]

Oh, i didn't even notice it's a 3rd party package which it depends on. Definitely that kind of rules should be plugins since not everyone wants to use all of the rules and now it causes lots of redundant extra dependencies for them. But as a user of the Stylelint, i'd like to find all the official/recommended(&others as well) plugins from a single place, maybe even from where core rules are defined.

[davidtheclark]

We can make these plugins, yes. It would certainly be nice if the original maintainers want to maintain stylelint plugins, too. If not, what's the plan?

[jeddy3]

But as a user of the Stylelint, i'd like to find all the official/recommended(&others as well) plugins from a single place,

Curated list of plugins at http://stylelint.io/user-guide/plugins/ - top level navigation item on the website and also linked to (twice) from the top of the rules page at http://stylelint.io/user-guide/rules/

@villesau FYI, creating, publishing and consuming stylelint plugins is pretty trivial and so perhaps the no-unsupported-browser-features plugin is something you'd like to champion and/or help the doiuse author maintain?

If not, what's the plan?

We had success with the release planning doc leading up to 7.0.0 i.e. the community filled the holes left by the property group structure and extract options, while the not-often-used hierarchicalSelectors option faded away. Hopefully the same will happen (between the deprecation and removal) this time around too. Otherwise, I think we can cross that bridge when we come to it.