Tailwindcss: Replace use of whitelist with allowlist and blacklist with denylist

[estevanmaito]

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: https://github.com/rails/rails/issues/33677

[adamwathan]

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]

This is being changed upstream: https://github.com/FullHuman/purgecss/issues/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.