Migrate data theme keys
#18816
Merged
Migrate data theme keys
#18816
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RobinMalfait
force-pushed
the
feat/upgrade-data-theme
branch
from
17b2f0a to
0e1549a
Compare
thecrypticace
approved these changes
Aug 28, 2025
RobinMalfait
force-pushed
the
feat/upgrade-aria-theme
branch
from
950eac2 to
ebfee41
Compare
RobinMalfait
force-pushed
the
feat/upgrade-data-theme
branch
from
0e1549a to
a08cb3d
Compare
But we will make sure that we skip the ones that would be handled automatically by bare values. E.g.: `data-foo:flex` will generate `[data-foo]`.
If you migrate both `aria-*` and `data-*` custom variants, then the output would look like this: ```css @custom-variant aria-bar (&[aria-baz="true"]); @custom-variant aria-asc (&[aria-sort="ascending"]); @custom-variant aria-desc (&[aria-sort="descending"]); @custom-variant data-checked (&[data-ui~="checked"]); ``` Instead of ```css @custom-variant aria-bar (&[aria-baz="true"]); @custom-variant aria-asc (&[aria-sort="ascending"]); @custom-variant aria-desc (&[aria-sort="descending"]); @custom-variant data-checked (&[data-ui~="checked"]); ```
RobinMalfait
force-pushed
the
feat/upgrade-data-theme
branch
from
a08cb3d to
894143b
Compare
RobinMalfait
added a commit
that referenced
this pull request
Aug 28, 2025
This PR is a follow up of #18815 and #18816, but this time let's migrate the `supports` theme keys. Let's imagine you have the following Tailwind CSS v3 configuration: ```ts export default { content: ['./src/**/*.html'], theme: { extend: { supports: { // Automatically handled by bare values (using CSS variable as the value) foo: 'foo: var(--foo)', // parentheses are optional bar: '(bar: var(--bar))', // Not automatically handled because names differ baz: 'qux: var(--foo)', // ^^^ ^^^ ← different names // Custom grid: 'display: grid', }, }, }, } ``` Then we would generate the following Tailwind CSS v4 CSS: ```css @custom-variant supports-baz { @supports (qux: var(--foo)) { @slot; } } @custom-variant supports-grid { @supports (display: grid) { @slot; } } ``` Notice how we didn't generate a custom variant for `data-foo` or `data-bar` because those are automatically handled by bare values. I also went with the longer form of `@custom-variant`, we could use the single selector approach, but that felt less clear to me. ```css @custom-variant supports-baz (@supports (qux: var(--foo))); @custom-variant supports-grid (@supports (display: grid)); ``` --------- Co-authored-by: Jordan Pittman <thecrypticace@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is similar to and a follow up of #18815, but this time to migrate the
datatheme keys.Let's imagine you have the following Tailwind CSS v3 configuration:
Then we would generate the following Tailwind CSS v4 CSS:
Notice how we didn't generate a custom variant for
data-foobecause those are automatically handled by bare values.