Always use restrictTo

[ai]

I suggest to always have allow-list of states, because right now we prefix :where(), :not() and many other CSS functions like this.

Even if we blacklist when, new will be added in the future. It is more likely to add new non-interactive pseudo-state.

[giuseppeg]

Good idea! I think that going for an allow-list approach makes sense.

In this case though we shouldn't use restrictTo in my opinion because if a user wants to add a pseudo class to the default ones they will have to rewrite interactiveStates by hand.

Since we want to go for an opt-in (allowlist) approach instead opt-out (blacklist), we should remove the concept of blacklist and restrictTo altogether and perhaps expose a custom option that is a function that should return an array of supported pseudo-classes. This function will get the list of default.

let defaultClasses = [':hover', ':active', ':focus', ':visited', ':focus-visible', ':focus-within'];

if (typeof options.custom === "function") {
   defaultClasses = options.custom(defaultClasses);
   if (false === Array.isArray(defaultClasses)) {
       throw new Error("options.custom: Invalid return value. The function should return an array of strings");
   }
}

[giuseppeg]

if you want options.custom can be polymorphic and be either the function above or an Array that will override everything

[ai]

@giuseppeg I updated API to custom

[giuseppeg]

Awesome thank you! We'll release 0.5.0 once all these changes are merged

[ai]

I need to merge it to master to make another PR

[ai]

I will add changes to that PR to avoid merging

[ai]

I also moved to modern JS syntax, but I think we need to merge #46 to fix CI.

But these 2 PRs is all changes which I am suggesting. We can merge them and release.

[giuseppeg]

Merged the other, feel free to rebase.

[ai]

Rebased and fixed. Merge and release when you will be ready.

[giuseppeg]

Thanks! Will do it tomorrow morning because I am not home

[giuseppeg]

similarly to pseudo classes we can add support for pseudo elements, defaulting to :before and :after only, we would need a matching custom option similar to the one for pseudo classes to customize these

[ai]

Can we have done it in separated PR? I am not sure why we need to process :after at all.

[giuseppeg]

since now we are using an allowlist pattern, this is not necessary right?

[ai]

I am not sure to be honest. Do you remember why you added it?