feat(core,presets)!: update presets to use the recursive callback

[chu121su12]

Follow up to #1126, this PR update the existing variants to use the introduced variant handler().

Closes #1104

This PR adds 2 extra properties on the handler. Variants that use selector sectioning (the one that uses $$: dark, rtl/ltr and group pseudo) are now moved into prefix so it can be modified selectively.

unocss/packages/core/src/types.ts

Lines 193 to 204 in 91ea249

	/**
	* Rewrite the output selector. Often be used to append parents.
	*/
	prefix: string
	/**
	* Rewrite the output selector. Often be used to append pesudo classes.
	*/
	selector: string
	/**
	* Rewrite the output selector. Often be used to append pesudo elements.
	*/
	pseudo: string

[netlify]

✅ Deploy Preview for unocss ready!

Name	Link
🔨 Latest commit	366a67b
🔍 Latest deploy log	https://app.netlify.com/sites/unocss/deploys/62b664c1605ce4000851077c
😎 Deploy Preview	https://deploy-preview-1127--unocss.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[antfu]

I'd suggest we only rewrite those necessary.

[antfu]

Can you help resolving the conflicts? Thanks

[sibbng]

@chu121su12 Thanks for your work on this. I was watching the changes in this PR and other related PRs and I was not really expecting this to be merged while snapshots are like that. This PR now removes the whole purpose of #987. I see this PR comes with some features to take more control over output. Having more features is nice, but it still seems a little bit incomplete.

Why we shouldn't fix #1104

The issue in #1104 is the consequence of the breaking change in #987. The point of #987 is applying variants in the same order as Tailwind to make migration as easy as possible. I don't understand why we are trying to fix #1104. The changes in #987 are not just about group and dark variants. Let's take a look at the example at #1104

Input:

<div class="checked:next:bg-red-50">
<div class="next:checked:bg-red-50">

Unocss output after #987 and before this PR

.checked\:next\:bg-red-50 + *:checked
.next\:checked\:bg-red-50:checked + *

Tailwind output Same as the above. I added next variant manually in config.

.checked\:next\:bg-red-50 + *:checked
.next\:checked\:bg-red-50:checked + *

Unocss output after this PR

.checked\:next\:bg-red-50:checked + *
.next\:checked\:bg-red-50 + *:checked

Now two same inputs have different outputs and behaviours between Unocss and Tailwind. We should revert this PR and suggest people to reverse their variants order.

/cc @antfu

[chu121su12]

My case for #1104 is that unocss syntax should follow the order of declaration, as in checked:next or next:checked shoud be applied in order.

@sibbng To your point, this changes is done on preset-mini. If we really want to preserve compatibility with tailwind, I think we should add override in preset-wind instead.

[chu121su12]

I added next variant manually in config.

Also, as this is not in the tailwind's core, I think it is on the same level as providing separate variant definition in unocss config.

[antfu]

I see, let's better align with Tailwind in this case. I guess having inverse behavior for wind / mini would be quite confusing. Let's revert the order. @chu121su12