Replies: 1 comment 5 replies
-
|
Assuming I'm understanding you correctly and the @layer theme {
* {
@variant dark {
--color-primary: theme(--color-blue-200);
}
}
}https://play.tailwindcss.com/SYEJ4bnAuH?file=css |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that's great. Thanks for your help here and on Discord. However that doesn't work when prefix is involved. @layer theme {
* {
@variant dark {
--tw-color-primary: theme(--color-blue-800);
}
}
}Also, I noticed that when the CSS is built, it produces: @layer theme {
@layer theme {
* {
&:where(.tw-dark, .tw-dark *) {
&:where(.tw-dark, .tw-dark *) {
--tw-color-primary: ...;
}
}
}
}
}So the |
Beta Was this translation helpful? Give feedback.
-
|
Seems a like a bug. |
Beta Was this translation helpful? Give feedback.
-
|
Do you know if the |
Beta Was this translation helpful? Give feedback.
-
|
What's the issue with it? |
Beta Was this translation helpful? Give feedback.
-
|
The prefix |
Beta Was this translation helpful? Give feedback.
-
I create share themes to be used is dozens of MFEs, each defines their own prefix to avoid CSS load order conflicts.
The theme uses variants for dark color theme, for example.
I can do that in Tailwind v3, but in v4 there are 2 problems:
@custom-variantcannot be nestedThis mean I can't add it to the share theme to specify the common variant mechanisms.
No theme mechanism to define variants
For example, I want the token
--color-primarymaps to--color-red-800in light theme and--color-blue-800in dark theme.The solutions I found are:
using class
using data-*
you can see that the
--tw-color-primaryand.tw-darkalso make the them not sharable/portable.Is there another way in Tailwind v4 that support this use case?
I have not only
@custom-variant darkbut also other variants, so the non-sharable part has a lot of definitions.Beta Was this translation helpful? Give feedback.
All reactions