fix: preserve light-dark in custom properties

[TheAlexLichter]

Resolves #821

This PR keeps the existing light-dark() polyfill for custom properties so old browser behavior and common design-system token patterns remain intact.

But it also adds native light-dark() @supports overrides for supporting browsers which includes correct handling for LAB/P3 fallbacks, !important, support checks like custom properties or var()/attr() fallbacks and redeclarations.

@property initial-value preserves native light-dark() as is because otherwise it would invalidate typed custom-property registration.

Main downside is more generated CSS for custom properties with light-dark() but only when targeting browsers that need the polyfill behavior.

[devongovett]

I would say that's a breaking change. I know the polyfill isn't perfect, but people are relying on it anyway.

[TheAlexLichter]

Back to the drawing board then. I'll try to come up with a solution that fixes light-dark() "better" while remaining backward-compatible with the current polyfill.

[MoritzLost]

@devongovett @TheAlexLichter Is it a breaking change to fix something that's already broken, though?

If people are relying on this transpiler feature, they most likely are not using color-scheme in the way described in the issue, or they would've run into this bug. If they did encounter the bug, they would have to have either disabled the feature, or implemented a workaround. In either case, nothing will break when the feature is only turned off in cases where it would trigger the bug at the moment.

[devongovett]

No, it's only broken in a very specific case when you set the color-scheme on a different element than the var. If you define your variables on the same element you set color-scheme it will work fine. This is a very common case, i.e. a design system usually sets it's tokens on a root-level element that also sets the color scheme. Removing this feature would break that.

Note that there is already a feature flag to disable LightDark if you want. We could consider a separate flag to disable it on vars I suppose.

[TheAlexLichter]

Tried something more sophisticated (which is slightly ugly and givesTokenList a bit more to do 🙈).

Also fine with switching to a new feature flag instead if you think that approach isnt the way.