Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace use of whitelist with allowlist and blacklist with denylist #1868

Closed
estevanmaito opened this issue Jun 1, 2020 · 3 comments
Closed

Comments

@estevanmaito
Copy link
Contributor

estevanmaito commented Jun 1, 2020

We can use better terminology and promote diversity.

Whitelists would become allowlists
Blacklists would become denylists

Right now, Tailwind makes use of the term 'whitelist' mostly in the docs and passing PurgeCSS options forward.

The first case would be relatively easy to change. The second one depends on PurgeCSS, but, we already have a layer over it, and could already start a change by:

  • adding a map to whitelist, whitelistPatterns and whitelistPatternsChildren inside Tailwind's purge options: allowlist, allowlistPatterns and allowlistPatternsChildren;
  • or, being more incisive and making the mapping inside options;

It's changing a third party package API, but it has to start somewhere. Good documentation on our side would reduce the friction (we already have it in place for Tailwind's layer) and send a message: we are doing our part.

edit: I can PR

inspired by Rails: rails/rails#33677

@estevanmaito estevanmaito changed the title Replace the use of white and blacklists Replace use of whitelist with allowlist and blacklist with denylist Jun 1, 2020
@adamwathan
Copy link
Member

I'm on board with using better terminology here but lets wait and see if PurgeCSS will change it upstream before adding an additional layer here. It would suck for us to choose one set of terms and them to choose another and have the APIs diverge from one another.

These terms don't actually appear in the Tailwind codebase at all, and the options key is just a way to access the raw PurgeCSS API, so I don't think aliasing things within options is the right approach in general anyways. It would be better for us to add our own top-level options with our own names so that there's no confusion about "does options just proxy to PurgeCSS or is it specific to Tailwind?".

I'll leave this open until a decision is made upstream but lets focus the discussion there.

@adamwathan
Copy link
Member

This is being changed upstream: FullHuman/purgecss#439

Since we don't actually use this language in Tailwind itself I'm going to close this, but if we ever do introduce abstractions on top of this functionality we will absolutely use the most inclusive terminology.

@sveisvei
Copy link

sveisvei commented Feb 4, 2021

Controlled speech is a form of evil, just saying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants