Rule Change: Add `allowSelectors` option to "use-baseline" rule

[Grapedge]

What rule do you want to change?

use-baseline

What change do you want to make?

Generate fewer warnings

How do you think the change should be implemented?

A new option

Example code

.foo {
  &:hover {
    color: red;
  }
}

What does the rule currently do for this code?

Selector 'nesting' is not a widely available baseline feature.

What will the rule do after it's changed?

After the change, if a selector is included in allowSelectors, it will not report an error even if it's not a baseline feature.

import css from '@eslint/css';

export default {
  files: ['**/*.css'],
  language: 'css/css',
  plugins: { css },
  languageOptions: {
    tolerant: true,
  },
  rules: {
    'css/use-baseline': [
      'error',
      { 
        available: 2021, 
        allowSelectors: ['nesting']  // ✅ New option
      }
    ],
  },
};

Participation

• I am willing to submit a pull request to implement this change.

Additional comments

Our project uses PostCSS to process CSS nesting selector syntax, so the syntax in the Example code is valid for our environment.

We currently cannot set the 'css/use-baseline' rule to 'error' because it would generate numerous false positives in our codebase.

We hope to configure an allowlist of non-baseline selectors in ESLint to prevent errors when using PostCSS features.

I'm uncertain whether similar allow-list options should be supported for other CSS constructs like properties, at-rules, media conditions or types. Currently, I don't know if anyone actually needs these.

[nzakas]

Thanks for the suggestion. I'm not sure we want to start slicing into baseline status in this way. Would setting the availability to "newly" serve your purpose?

[Grapedge]

I've tried both available: "newly" and available: 2023 - they both work fine with this syntax. However, we still need to maintain 2021 baseline compatibility for a portion of our user base using older browsers.

[nzakas]

Ah gotcha, I totally missed that part in the config.

Can you help me understand a bit more: if you want to keep 2021 as your baseline, why do you want to specifically allow something that isn't supported? Wouldn't that defeat the purpose?

[rviscomi]

Our project uses PostCSS to process CSS nesting selector syntax, so the syntax in the Example code is valid for our environment.

I wonder if the right solution is to reconfigure ESLint to check the post-processed (production-ready) stylesheet instead?

[nzakas]

@rviscomi I think the problem with that is they don't get the realtime feedback in the editor.

Also, thanks for reminding me that they are post-processing.

I'm still on the fence about whether or not we want to let people slice and dice parts of baseline, because if we add allowSelectors, then we'll need to add options for every piece of syntax (allowProperties, allowUnits, etc.) and I'm just not sure that's leading down a beneficial path.

[rviscomi]

Stylelint actually did something similar: ryo-manba/stylelint-plugin-use-baseline#22. I definitely get the usefulness of centrally allowlisting features, but I kind of wish developers didn't have to manage it in the first place.

@nzakas is there any precedent for ESLint adapting its behavior in the presence of other code transformation tools? For example, maybe it could automatically suppress warnings for things it knows will be handled by the other tool.

Also, I wonder if this is a common problem as there were a couple of negative reactions to #85, where I suggested adding support for this selector.

[Grapedge]

I wonder if this is a common problem

I believe this is quite common. A similar discussion can be found in #152, and Tailwind 4 likewise uses Lightning CSS to handle nesting syntax.

I analyzed the reports generated by the css/use-baseline rule in our component package. They can generally be grouped into two categories:

• We don’t want to report errors: features that are compatible via postcss-preset-env, such as nesting selectors and backface-visibility;
• We do want to report errors: features that are not compatible, such as text-wrap.

/* Original */
.foo {
  /* Selector 'nesting' is not a 2021 baseline feature */
  & .bar {
    /* Property 'text-wrap' is not a 2021 baseline feature */
    text-wrap: balance;
    /* Property 'backface-visibility' is not a 2021 baseline feature */
    backface-visibility: hidden;
  }
}

/* After PostCSS */
.foo .bar {
  /* Property 'text-wrap' is not a 2021 baseline feature */
  text-wrap: balance;
  -webkit-backface-visibility: hidden;
  /* Property 'backface-visibility' is not a 2021 baseline feature */
  backface-visibility: hidden;
}

[EgoziE]

+1 for this, we have a strong need for this at Wix as well.

The ability to explicitly allow and deny certain CSS features is critical for us. We want to enforce a general baseline (widely available), but we also need an ignore-list for properties we don't want to be used and an allow-list for newer features we've approved for use. (according to our own usage data)

Having both capabilities would give us the maximum flexibility to enforce our specific CSS standards at scale. 🕵🏼‍♂️

[nzakas]

@rviscomi thanks for the Stylelint reference. That's a good argument for adding exceptions, and as I was saying, we really can't just set up allowing specific selectors -- if we make a change, we need to make it so that there are exceptions to each part of the rule in a consistent way.

is there any precedent for ESLint adapting its behavior in the presence of other code transformation tools? For example, maybe it could automatically suppress warnings for things it knows will be handled by the other tool.

No. ESLint doesn't know about any other tools in the environment, nor do I think it should.

---

Since it seems like there's some agreement that these types of options are helpful, I'll propose we start out by mimicking the three that Stylelint has:

• allowSelectors - allows selectors by name
• allowProperties - allows properties by name
• allowAtRules - allows at-rules by name

@Grapedge are you interested in implementing these?