Simplify hovers

[maddymeows]

Enables hovers to replace the class name with a simple & to better help understand what the selector is doing.

Sometimes it is necessary to write code that gets as complex as [&[aria-selected=true]:has(+_:not([aria-selected=true]))::before]:border-purple-500. I often reach to hover over the class to make sure it is doing what I intended. Unfortunately the current implementation's hover puts out this code:

.\[\&\[aria-selected\=true\]\:has\(\+_\:not\(\[aria-selected\=true\]\)\)\:\:before\]\:border-purple-500[aria-selected=true]:has(+ :not([aria-selected=true]))::before {
  --tw-border-opacity: 1;
  border-color: rgb(168 85 247 / var(--tw-border-opacity));
}

I would not blame you if you had no idea what this selector was doing, and the noise gets amplified by the word wrapping that VS code does. It takes quite a lot of time to precisely figure out which part of this selector is relevant. With my changes the hover would instead show the following:

&[aria-selected=true]:has(+ :not([aria-selected=true]))::before {
  --tw-border-opacity: 1;
  border-color: rgb(168 85 247 / var(--tw-border-opacity));
}

I've opted to make this default behaviour as I believe this is the better experience to provide by default.

[thecrypticace]

I really like the idea in a general sense but I think we want to approach this in a different way. In v4 we use native CSS nesting syntax which, in intellisense, helps with understanding what each variant applied to a class is doing.

For example, instead of using one long arbitrary variant you can write the class you have like so in v4:

aria-selected:[&:has(+_:not([aria-selected=true]))]:before:border-purple-500

And when hovering over it you'll get this:

And each variant is separated here so it's easier to see what is happening. Given that, I think if we were to do anything here it would be to add a feature that tries to convert the flattened CSS to nested CSS. And we won't need to do this in v4 because it'll just work that way by default.

I'm gonna close this but I'll make a note internally to investigate what it would take to "unflatten" CSS for earlier Tailwind versions and see if we want to offer an option for that if it's ends up being workable.