Don't rely on existence of --default-transition-* variables in transition utilities#13219
Don't rely on existence of --default-transition-* variables in transition utilities#13219adamwathan merged 4 commits intonextfrom
Conversation
| `) | ||
| }) | ||
|
|
||
| test('utilities that rely on the --default namespace still work when using `@theme reference`', () => { |
There was a problem hiding this comment.
Not sure if this test is really needed since this change is reflected in the utilities tests. Maybe better to test this there specifically for the transition utilities with new test cases for providing these two variables both with @theme and with @theme reference.
|
Shouldn't the default be 150ms, not 0s? tailwindcss/stubs/config.full.js Line 935 in d86fd0b |
ebf47e9 to
2ac9976
Compare
@Steffan153 So the default value here isn't meant to be the default theme value, it's the value to use if the person has explicitly disabled the default theme by not importing it. Since the The value is still respected even when using expect(
compileCss(
css`
@theme reference {
--default-transition-duration: 150ms;
}
@tailwind utilities;
`,
['transition-all'],
),
).toMatchInlineSnapshot(`
".transition-all {
transition-property: all;
transition-duration: .15s;
transition-timing-function: ease;
}"
`)The only time we'll fall back to |
This is more consistent with how things worked in v3 and ensures things will still work if the user suppresses the output of all CSS variables.
This PR fixes an issue where using
@theme reference { ... }would cause thetransition-*to stop working properly because they were relying on theme variables being present in the generated CSS.Right now this also inlines the values of those variables rather than emitting a
var(...)call. This is fine because we generally inline values of all variables currently, but if we decide to usevar(...)for everything we'll want to update this.Fixes #13215.