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

[estevanmaito]

We can use better terminology and promote diversity.

As stated in the CODE_OF_CONDUCT:

• Using welcoming and inclusive language
• Being respectful of differing viewpoints and experiences
• Gracefully accepting constructive criticism
• Focusing on what is best for the community
• Showing empathy towards other community members

Whitelists would become allowlists
Blacklists would become denylists

This is what I proposed for Tailwind CSS (https://github.com/tailwindcss/tailwindcss/issues/1868) to map to PurgeCSS' options:

• whitelist -> allowlist
• whitelistPatterns -> allowlistPatterns
• whitelistPatternsChildren -> allowlistPatternsChildren

The unwelcoming terms could still be supported, but no more documented. It would not break any code already using it but would enforce better standards for future.

It has to start somewhere. Good documentation on our side would reduce the friction and send a message: we are doing our part.

I'm not familiar with the codebase, but would be willing to make these changes as in most of the cases it would be documentation and renaming (yes, I propose to also change internal code, but leave the minimum necessary to keep old properties working)

inspired by Rails: https://github.com/rails/rails/issues/33677

[Ffloriel]

I don't see how whitelist and blacklist are unwelcoming terms as they are well-known technical terms.
Would you mind adding a +1 to this issue?
It will give an idea if the feeling is shared. Ultimately, it's a variable name so I'm not against changing it if that's the case.

[estevanmaito]

I think most of the discussion already happened here https://github.com/rails/rails/issues/33677

Regardless of origin, allow/deny are simply clearer terms that does not require tracing the history of black/white as representations of that meaning. We can simply use the meaning directly.

I used the word _unwelcoming_ specifically because it is in the CoC: Using welcoming and inclusive language

I agree with you, but being well-known doesn't imply being correct. It's been used for a long time, most of us never payed attention to it, and it describes a lot o what is happening now outside of tech.

And if it helps people in doubt, no opinion is already an opinion. It will stay the same.

[leeoniya]

the origins of these terms are not rooted in racism. i'm generally against changing terminology based on this week's contextual use of them. "retarded" is another example - a perfectly valid term, both medically and in engineering. should it be scrubbed from future work because someone started using it disparagingly? this isn't the same as the washington redskins thing.

anyways, that's my unsolicited $0.02.

either way, allow/deny are both clear terms and aside from a BC perspective, i don't see an issue with this. there are other examples when the politically correct replacements are clearly worse, but that's not the case here.

[estevanmaito]

@leeoniya I'm not here to advocate to A or B, but your opinion doesn't match with historical research:

https://jmla.pitt.edu/ojs/jmla/article/view/490
https://www.etymonline.com/word/blacklist
https://inews.co.uk/news/government-cyber-experts-blacklist-whitelist-racism-fears-2840970

As cited before, it would have already saved us time:

simply clearer terms that does not require tracing the history of black/white as representations of that meaning.

[leeoniya]

https://en.wikipedia.org/wiki/Blacklisting#Origins_of_the_term

hmm, its first known use does coincide with that time period.

[enderton]

wholehearted +1000

[adamwathan]

I think that especially since this can be done with no breaking changes there's no reason not to use try and use less divisive terminology here.

I think the proposed allowlist and denylist are not great because the definitions of the words allow and deny aren't perfect metaphors for what the options do — they make sense in other contexts but here it's more about _preserving_ than _allowing_. I think when making a change like this we should aim to choose a name that is not only more inclusive than "whitelist" but also _better_, like DHH talks about in the linked Rails issue.

It's worth noting is that there is no "blacklist" feature/option in PurgeCSS currently, so we only really have to think of something for "whitelist".

I've been thinking through different options and I think the one I like most is safelist. It's actually shorter than whitelist, and has history of being used in place of "whitelist" in other contexts, like email for example.

[Ffloriel]

I will open an issue about what I have in mind for whitelisting in the future. But to summarize:

• agree about the variable name being changed. I share your opinion @adamwathan about allowlist and denylist, they don't really fit those options and those terms would be confusing from my perspective. I was thinking of includeList and excludeList instead but could be something else too. They also have been used to replace "whitelist" and "blacklist" and fit better what those options do.

• Whitelisting has changed a lot in PurgeCSS since the beginning and is a bit overcomplicated now. So I'm aiming to simplify it. Need to think of an easy way to define what we have right now (whitelist, whitelistPatterns, whitelistPatternsChildren, Greedy in an open PR, whitelisting specific to classnames and ids, the possibility to whitelist keyframes and CSS variables) and adding blacklist feature.

[Ffloriel]

Progress tracked in #439