Remove text opacity CSS variables from ::marker

[thecrypticace]

The rules that use the ::marker pseudo class only allow certain variables to be defined. In Safari it's likely there's an allowlist of some kind and it doesn't include custom properties. This prevents the default Tailwind text colors from working because we reference alpha values as the textOpcity plugin is on by default. To work around this you can disable the textOpacity plugin. This is definitely a browser bug that needs to be reported however it's also super not ideal that the out-of-the-box experience is broken for Tailwind here so we'll do something similar to our solution with ::visited and strip the text opacity property from rules and declarations.

This additionally fixes a bug where mutations to container and use of modifySelector did not preserve selectors when returning an array from a variant function.

Basically it turns this:

.marker\:text-red-500 *::marker {
  --tw-text-opacity: 1;
  color: rgb(239 68 68 / var(--tw-text-opacity));
}
.marker\:text-red-500::marker {
  --tw-text-opacity: 1;
  color: rgb(239 68 68 / var(--tw-text-opacity));
}

into this:

.marker\:text-red-500 *::marker {
  color: rgb(239 68 68);
}
.marker\:text-red-500::marker {
  color: rgb(239 68 68);
}

Fixes #8610

[thecrypticace]

@RobinMalfait I had to tweak applyVariant to store the original selectors on the rules themselves because cloning the mutated node causes it to treat it has not having been "backed up" so it doesn't restore the selectors like it should.

The only knock on effect is that I think this is more likely to correctly rewrite selectors in plugins that add variants that clone rules whereas they wouldn't have been before (… at least I don't think).

Does this fix seem okay to you?

[RobinMalfait]

A few questions but I think that makes sense. Can't wait to remove the modifySelectors code in v4 so that we only keep the new API and the container mutations directly 😄

[RobinMalfait]

Nit: use let instead for consistency

[RobinMalfait]

I was like lol "chicken out" and then I realised this was already there...

[RobinMalfait]

I'm a bit confused about why this moved 🤔

[adamwathan]

I think what's happening is the utilities are being grouped by utility now instead of by the selector, it's like:

.marker\:poop *::marker {}
.marker\:poop::marker {}

.marker\:banana *::marker {}
.marker\:banana::marker {}

.marker\:tonsils *::marker {}
.marker\:tonsils::marker {}

...instead of:

.marker\:poop *::marker {}
.marker\:banana *::marker {}
.marker\:tonsils *::marker {}

.marker\:poop::marker {}
.marker\:banana::marker {}
.marker\:tonsils::marker {}

I'd have to think about it harder but it feels like there was an important reason we originally did it by selector, so we probably want to be careful here. It's tricky admittedly for the reasons we talked about the other week, where variants registered within a function share a sort order or whatever.

I wonder if what we really want is to make this API possible for this one:

addVariant('marker', [() => {...}, () => {...}])

...so we can know the count up front and adjust the sort appropriately?

[thecrypticace]

Good news @adamwathan that API already works :D — I've updated the PR to switch to it

[thecrypticace]

@RobinMalfait @adamwathan I've addressed your feedback — ping me if there's anything else that needs to be looked at. I'd like to merge this in and tag a release today.

[RobinMalfait]

I think this looks good now!