Add @headlessui/tailwindcss plugin

[RobinMalfait]

This PR adds a new @headlessui/tailwindcss plugin so that you can style your components using just
the css without requiring a render prop or a v-slot in your templates.

Before:

<Menu.Button as={Fragment}>
  {({ open }) => (
    <button className={open ? 'text-blue-500' : 'text-red-500'}>
      Options
      <svg className={open && 'rotate-90'}>
        <path ... />
      </svg>
    </button>
  )}
</Menu.Button>

After:

<Menu.Button className="ui-open:text-blue-500 ui-not-open:text-red-500">
  Options
  <svg className="ui-open:rotate-90">
    <path ... />
  </svg>
</Menu.Button>

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
headlessui-react	✅ Ready (Inspect)	Visit Preview	May 24, 2022 at 7:26PM (UTC)
headlessui-vue	✅ Ready (Inspect)	Visit Preview	May 24, 2022 at 7:26PM (UTC)

[adamwathan]

[ecklf]

[hailwood]

@RobinMalfait I'm curious about the addition of the ui-not-x prefixes.
Isn't ui-not-selected:text-red ui-selected:text-green then same as text-red ui-selected:text-green?
I.e. aren't the not states just the default and should be overridden by the ui-x states since variants are listed after the base utilities in the final css?

[RobinMalfait]

@hailwood in a lot of cases that's true, but you can also combine those and then it can be useful: ui-active:ui-not-selected:...

Here is an example where you explicitly check for the ui-not-selected case as well: https://play.tailwindcss.com/HfMdcJk8yp

[cairin]

The ui-not-x feels like a tailwind anti-pattern.

I say this because, as far as I can tell, this new plugin is only used for state variants. And traditionally state variants only have additive value. i.e. you dont have a not-focus state variant in normal tailwind.

As for your example:
text-blue-500 ui-active:ui-not-selected:text-red-500 is the same as text-blue-500 ui-active:text-red-500 ui-active:ui-selected:text-blue-500. https://play.tailwindcss.com/rd5RDfrjB2

You could argue that the second option is more code, but it's also (maybe) more verbose. It's also more familiar when compared to other tailwind classes.

I suppose you could just not use the ui-not- variants. But it's adding complexity to tailwind, that maybe isn't needed.

[adamwathan]

The ui-not-x feels like a tailwind anti-pattern.

Totally see what you're saying and agree on the simplicity sticking to things being additive most of the time but I don't think this is an anti-pattern, to me it's no different than how we have support for both valid and invalid pseudo-classes:

We also recently added the enabled class for similar reasons:

tailwindlabs/tailwindcss#7905

We'll likely be merging this PR or some flavor of it that adds not-focus, not-hover, etc. too:

tailwindlabs/tailwindcss#7976

I don't think people will need to reach for this stuff super often but I think it's helpful to have 👍🏻