Create variants for aria, supports, and data JS config theme keys

[philipp-spiess]

This PR adds support for the aria, supports, and data properties found in JS config options. In v3, you could extend the theme to add more variants by using an object syntax like this:

{
   theme: {
    extend: {
      aria: {
        polite: 'live="polite"',
      },
      supports: {
        'child-combinator': 'h2 > p',
      },
      data: {
        checked: 'ui~="checked"',
      },
    },
  }
}

Since we no longer rely on theme variables for these variants, the way to make this work is by adding custom variants for each of these manually added variants.

[adamwathan]

Should we actually replace the root data/supports/aria variants here maybe so all the custom ones stay grouped with the arbitrary ones in the generated CSS?

[philipp-spiess]

Should we actually replace the root data/supports/aria variants here maybe so all the custom ones stay grouped with the arbitrary ones in the generated CSS?

Can you think of ways where the grouping would be important here? I feel like it would be weird to replace core utilities that are perfectly functioning. Makes it feel brittle because we could create a wrong implementation at any of the two places now or we forget to update one, etc.

[adamwathan]

Can you think of ways where the grouping would be important here?

@philipp-spiess Here's an example of where it would be a breaking change:

v3 registering aria-current in the config

https://play.tailwindcss.com/noQ9ZX69LZ

v4 adding a new separate aria-current variant

https://play.tailwindcss.com/qFyxAsRDt6

Likelihood of affecting anyone is quite small realistically but it is technically a breaking change.

Another option is to explicitly register the custom ones with the same order as the corresponding existing variants. This isn't possible with our currently exposed APIs I don't think but I'm sure we could come up with a way to do it by just making it possible to pass an explicit order when registering a variant but making it optional.

[philipp-spiess]

@adamwathan Ahh, thank you for the examples, I see the issue now 🤕. Yea we'd have to make it so that we can overwrite the order and then do a design system lookup for the default variants. What I don't like about this is that now we have to add a new API to core that is only needed for the compatibility work. When we eventually remove it, we will for sure forget to remove this new order option too... Hmmm.

We could make it work I think by kinda like "patching" the default functional variants? It seems like overwriting a utility does not change it's order! Let me try something. 👀

Edit: I realize this is probably what you have meant by your initial comment all along 🤦

[philipp-spiess]

@adamwathan Check out this tech: 5dcb301

[adamwathan]

Had a really old review I started and forgot to submit so just submit it now before I forget, probably had some outdated stuff and haven’t looked at everything yet either, on phone heh.