To make this a tiny bit worse, these properties also accept var(--my-name-reference) where the variable --my-name-reference could reference a dashed-ident such as --my-name.
This makes the bg-[--my-color] ambiguous because we don't know if you want var(--my-color) or --my-color.
With this PR, we bring back the automatic var injection feature as syntactic sugar, but we use a different syntax to avoid the ambiguity. Instead of bg-[--my-color], you can now write bg-(--my-color) to get the same effect as bg-[var(--my-color)].
This also applies to modifiers, so bg-red-500/[var(--my-opacity)] can be written as bg-red-500/(--my-opacity). To go full circle, you can rewrite bg-[var(--my-color)]/[var(--my-opacity)] as bg-(--my-color)/(--my-opacity).
This is implemented as syntactical sugar at the parsing stage and handled when re-printing. Internally the system (and every plugin) still see the proper var(--my-color) value.
Since this is also handled during printing of the candidate, codemods don't need to be changed but they will provide the newly updated syntax.
E.g.: running this on the Catalyst codebase, you'll now see changes like this:
Whereas before we converted this to the much longer min-w-[var(--button-width)].
Additionally, this required some changes to the Oxide scanner to make sure that ( and ) are valid characters for arbitrary-like values.
This PR re-introduces the automatic var injection feature.
For some backstory, we used to support classes such as
bg-[--my-color]that resolved as-if you wrotebg-[var(--my-color)].The is issue is that some newer CSS properties accepts dashed-idents (without the
var(…)). This means that some properties acceptview-timeline-name: --my-name;(see: https://developer.mozilla.org/en-US/docs/Web/CSS/view-timeline-name).To make this a tiny bit worse, these properties also accept
var(--my-name-reference)where the variable--my-name-referencecould reference a dashed-ident such as--my-name.This makes the
bg-[--my-color]ambiguous because we don't know if you wantvar(--my-color)or--my-color.With this PR, we bring back the automatic var injection feature as syntactic sugar, but we use a different syntax to avoid the ambiguity. Instead of
bg-[--my-color], you can now writebg-(--my-color)to get the same effect asbg-[var(--my-color)].This also applies to modifiers, so
bg-red-500/[var(--my-opacity)]can be written asbg-red-500/(--my-opacity). To go full circle, you can rewritebg-[var(--my-color)]/[var(--my-opacity)]asbg-(--my-color)/(--my-opacity).This is implemented as syntactical sugar at the parsing stage and handled when re-printing. Internally the system (and every plugin) still see the proper
var(--my-color)value.Since this is also handled during printing of the candidate, codemods don't need to be changed but they will provide the newly updated syntax.
E.g.: running this on the Catalyst codebase, you'll now see changes like this:
Whereas before we converted this to the much longer
min-w-[var(--button-width)].Additionally, this required some changes to the Oxide scanner to make sure that
(and)are valid characters for arbitrary-like values.