Rejected -webkit-background-clip with text value

[brunodccarvalho]

What minimal example or steps are needed to reproduce the bug?

.gradient {
  -webkit-background-clip: text;
  background-clip: text;
  -webkit-text-fill-color: transparent;
  -moz-text-fill-color: transparent;
}

What minimal configuration is needed to reproduce the bug?

{
  "defaultSeverity": "error",
  "rules": { "property-no-vendor-prefix": true }
}

How did you run Stylelint?

npx stylelint --config=.stylelintrc.json test.css

Which Stylelint-related dependencies are you using?

15.11.0

What did you expect to happen?

Since the rule does not delete the prefixed text-fill-color properties I expect no problems to be reported as -webkit-background-clip: text also seems to have very widespread support.

postcss/autoprefixer has a 5 year old test to accept this here, see background-clip.css

What actually happened?

test.css
 2:3  ✖  Unexpected vendor-prefix "-webkit-background-clip"  property-no-vendor-prefix

1 problem (1 error, 0 warnings)

and it is autocorrectable, so it gets replaced with background-clip: text if --fix is given

Do you have a proposal to fix the bug?

No response

[brunodccarvalho]

Apologies, I should clarify that the unprefixed property is not equivalent as background-clip: text does not currently work on chrome or edge, as shown on the caniuse page.

[Mouvedia]

Why aren't you using ignoreProperties?

[brunodccarvalho]

I am expecting stylelint to not transform correct to incorrect code silently, especially for css constructs and features that have essentially complete browser support. If it reports an error and refuses to fix the property I would consider that fine. Is this an unreasonable expectation?

[Mouvedia]

I am expecting stylelint to not transform correct to incorrect code silently

Hypothetically if we were targeting only Firefox 49–121, Edge 15–18 and Safari 14–17.2—which all support background-clip: text;—wouldn't the error be regarded as expected and desirable?
It seems that you are taking a subjective take on this; the rule doesn't discriminate based on browser support.
IMHO using this rule without exceptions spells trouble: it has to be constantly maintained.

[brunodccarvalho]

The rule is enabled by default in stylelint-config-standard with no exceptions.

When it comes to the css, as you can see in the caniuse page, the -webkit-background-clip name for this property value has been supported for a decade, the webkit browsers seem to have no interest in migrating to background-clip, and the non-webkit browsers support the -webkit- prefix. Browser targeting is largely irrelevant in this case when the unprefixed version has 20% support, the prefixed one has 95%, the latter is a superset of the former, and there seems to be no interest in changing this. The prefixed version is de facto standard.

Looking around in lib/utils/isAutoprefixable.js, #5312, #4971 and postcss/autoprefixer/lib/hacks, this looks like it was missed in #5312.

In isAutoprefixable.js a manual whitelist is used to list target properties, rather than a blacklist or something dynamic. This suggests the rule is meant to be conservative and safe, and remove only historically superfluous prefixes like -moz-columns and -webkit-transform. With this implementation approach I expect the user should not need to worry with this rule breaking conforming up-to-date css. I think stylelint-config-standard would agree.

Scanning postcss/autoprefixer/lib/hacks I found similar hacks for mask-border, which seems to be handled correctly here, and another for background-size, which seems to be handled unsafely according to wg-compat#28. I suggest removing it from the whitelist.

In #5312 -ms-interpolation-mode is a "positive" exception, we should do the same here, this is a "negative" exception, we'll need to know the value in the declaration like the autoprefixer hack does. I'll submit the short PR in a minute.

[ybiquitous]

@brunodccarvalho Thanks for the explanation. I understand your motivation well. But I think stylelint-config-standard should handle this case, instead of the Stylelint core logic. Reasons:

• The motivation of Refactor to remove autoprefixer dependency #5312 was to reduce dependency on code around vendor prefixes, which are "are on their way out in favour of browser flags" (as Refactor *-no-vendor-prefix to avoid using autoprefixer #5293 said).
• background-clip: text is not currently supported in the CSS Background Level 3 spec.
• The Level 4 spec may support the text value in the future (see Remove -webkit-background-clip from compat spec. whatwg/compat#195 as a good resource). If supported, an irregular code like PR Add background-clip-text exception in property-no-vendor-prefix #7295 might be unneeded.
• Creating a breaking change, such as making -webkit-background-clip a lint problem, is much easier in stylelint-config-standard than stylelint.

Any thoughts?

[Mouvedia]

But I think stylelint-config-standard should handle this case, instead of the Stylelint core logic.
Creating a breaking change […] is much easier in stylelint-config-standard than stylelint.

I think that's the right course of action. @brunodccarvalho were you using the standard config?
If so this issue can be transferred to stylelint/stylelint-config-standard.

[brunodccarvalho]

background-clip: text is not currently supported in the CSS Background Level 3 spec.

That you present this as a serious argument demonstrates the project targets the idealized web rather than the de facto web, which I do not consider reasonable for a tool like this. I'll add my exceptions to background-clip and background-size internally and end my contribution to this matter here.

[Mouvedia]

@ybiquitous I think we should propose to add exceptions here.

@brunodccarvalho thanks for the feedback but stylelint/stylelint is just not the right place for this change.
The existing exception is a bad precedent IMHO but it's too late to revert now.

[ybiquitous]

I think we should propose to add exceptions here.

Agree. Feel free to open a Pull Request.

The existing exception is a bad precedent IMHO but it's too late to revert now.

Yes, we should not have added this exception.

[Mouvedia]

-webkit-background-clip is part of the legacy name aliases list.