Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-introduce automatic var injection shorthand #15020

Merged
merged 13 commits into from
Nov 18, 2024

Conversation

RobinMalfait
Copy link
Member

@RobinMalfait RobinMalfait commented Nov 17, 2024

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 wrote bg-[var(--my-color)].

The is issue is that some newer CSS properties accepts dashed-idents (without the var(…)). This means that some properties accept view-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-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:
image

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.

@RobinMalfait RobinMalfait force-pushed the feat/automatic-var-injection branch 2 times, most recently from 71e621c to b696bc3 Compare November 18, 2024 11:26
@RobinMalfait RobinMalfait changed the title Re-introduce automatic var injection Re-introduce automatic var injection shorthand Nov 18, 2024
@RobinMalfait RobinMalfait marked this pull request as ready for review November 18, 2024 11:34
@RobinMalfait RobinMalfait requested a review from a team as a code owner November 18, 2024 11:34
This parses it as an arbitrary value where the `var(…)` surroundings are
omitted.
Fallbacks, dataType hints and modifiers also get the same treatment.
Combine the `in_arbitrary` and `idx_arbitrary_start` variables into an
enum. In the next commit we will introduce the `Arbitrary::Parens` state
for arbitrary value shorthand for variables. E.g.: `bg-(--my-var)`.
@RobinMalfait RobinMalfait force-pushed the feat/automatic-var-injection branch from 7355087 to ba164be Compare November 18, 2024 12:58
CHANGELOG.md Outdated Show resolved Hide resolved
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
@RobinMalfait RobinMalfait merged commit 3dc3bad into next Nov 18, 2024
1 check passed
@RobinMalfait RobinMalfait deleted the feat/automatic-var-injection branch November 18, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants