MichaelAllenWarner

@adamwathan wrote: > Hey thanks for this! My only hesitation on merging is around the API — I've always sort of dreamed of coming up with a way to make...

@adamwathan > Yeah no conflict just don't like having two ways to do things or having to keep around old code for backwards compatibility if we come up with a...

😬 So I guess there are two related implementation questions here: 1. In what order should the `not-` variants be registered in relation to the existing variants? 2. In what...

> Is there a valid situation anyone can think of where it makes sense to add two not- classes that both set the same CSS property at once? Not off-hand,...

> I'm also realizing now maybe the `group` and `peer` stuff are actually in a bad order already too — this demo seems bad to me: > > https://play.tailwindcss.com/8dsV6plUrt Would...

> Would switching the registration order of `hover` and `group-hover` actually make a difference there, though? Isn't that one just a matter of specificity? And I guess if that's right,...

Heh, same wavelength on the `:where()` business.

The PR now registers the `not-` variants first (this required reordering things in `tests/variants.test.css`). It also has `not-` tests for the new `optional:` variant and for `hover:` when `hoverOnlyWhenSupported` is...

@bastien70 @libreajans Try replacing `enforceSize(...)` with `enforceSpaceOrLineBreak(...)` where appropriate in `RulesetBuilder.php`. For the ternaries, that would be lines [225](https://github.com/friendsoftwig/twigcs/blob/main/src/RegEngine/RulesetBuilder.php#L225) and [227](https://github.com/friendsoftwig/twigcs/blob/main/src/RegEngine/RulesetBuilder.php#L227).

Marked as draft because the PR's current `group-not-` and `peer-not-` implementation doesn't support the new nested-modifier syntax (like `group-not-hover/sidebar:opacity-75`).