Skip to content

[v4] transition-property Theme CSS Variables #16639

New issue

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

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

Already on GitHub? # to your account

Open
mshimokura opened this issue Feb 18, 2025 · 4 comments · May be fixed by #18056
Open

[v4] transition-property Theme CSS Variables #16639

mshimokura opened this issue Feb 18, 2025 · 4 comments · May be fixed by #18056

Comments

@mshimokura
Copy link

What version of Tailwind CSS are you using?

v4.0.6

What build tool (or framework if it abstracts the build tool) are you using?

Next.js: 15.1.3

What version of Node.js are you using?

v20.18.1

What browser are you using?

Safari

What operating system are you using?

macOS

Reproduction URL

https://play.tailwindcss.com/pNcjYumxXW

Describe your issue

Overview

I am trying to migrate a project to v4, which has custom transition properties defined in the config.

Previously:

// tailwind.config.ts
theme: { extend: { transitionProperty: { ring: 'box-shadow' } } }

// component.tsx
<input className="transition-[theme(transitionProperty.colors),theme(transitionProperty.ring)]" />

Expected migration:

// globals.css
@theme {
  --transition-property-ring: box-shadow;
}

// component.tsx
<input className="transition-[theme(--transition-property-colors),theme(transition-property-ring)]" />

Specifics

The included transition properties are not included as css variables (i.e. theme(--transition-property-colors) does not work), but it does work with the old syntax, i.e. theme(transitionProperty.colors).

Similar to the previous report in #14479, using the default transition properties (i.e. transition-colors) does not output css variables.

Also, for example, --transition-property-ring: box-shadow does work in the @theme declaration but it is not documented (afaict). If you would like this raised as a separate documentation issue I can do that, but I think that it may change based on how the default transition properties are implemented (i.e. should they also be css variables in the documentation?)

@philipp-spiess
Copy link
Member

Hey! So the reason for this is that we no longer have the default transition property list as CSS variables as we realized nobody was really changing the defaults here besides maybe adding new presets (which is still supported). Because of the backward compatibility though, the old syntax (transitionProperty.colors) will still work for now but since these aren't CSS vars, the new syntax won't right now.

What you can do for now is to create other named transition properties that contain the mixture of properties that you are often using in your app, e.g.:

@theme {
  --transition-property-ring: box-shadow;
  --transition-property-ring-color: box-shadow, color, background-color, border-color, outline-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to;
}

This way you can just use transition-ring and transition-ring-colors and don't have to worry about what is present as a CSS variable and not (You can find the other defaults here: https://github.com/tailwindlabs/tailwindcss/blob/main/packages/tailwindcss/src/utilities.ts#L3594-L3601)

Going to leave this open so we have time to think over this a bit though, thanks!

@mshimokura
Copy link
Author

Thanks for the response & consideration!

I can certainly appreciate that these are 'special' values that perhaps don't really belong in the "theme" (since nobody would really change them), and I do appreciate that they're still extensible.

However, I think that if the theme() function is really supposed to "evolve" to the new version, then they should be made available that way. Or perhaps they belong in some new class of "static" css variables, or accessible via some sort of static function instead?

I do think though, given that you can extend them by editing the @theme directive, they should be elevated to true theme status for consistency.

One other thought that I had, was that the transition-colors utility also changed to include outline-color and perhaps if someone wanted to customize their theme to revert that, then that might be supported if transition-property was changed to be a first-class theme property & transition's default also used those theme css variables.

For example in this playground, we can override transition-colors but it outputs two css classes, and transition (default) does not take into account that transition-colors was overriden: https://play.tailwindcss.com/tNvFvk7pR1

  @theme {
    --transition-property-colors: color, background-color, border-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to;
  }
  /* ... */
  .transition-colors {
    transition-property: color, background-color, border-color, outline-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to;
    transition-timing-function: var(--tw-ease, var(--default-transition-timing-function));
    transition-duration: var(--tw-duration, var(--default-transition-duration));
  }
  .transition-colors {
    transition-property: var(--transition-property-colors);
    transition-timing-function: var(--tw-ease, var(--default-transition-timing-function));
    transition-duration: var(--tw-duration, var(--default-transition-duration));
  }

@cofl
Copy link

cofl commented Feb 21, 2025

nobody was really changing the defaults here

As one of the nobodies who changed the defaults to include @property's for --tw-gradient-from-position and friends, it would be really nice to have any way at all to configure these.

@nicolas-cusan
Copy link

I change the default transition property value on most of my projects. It would be great to have a way to custumize it via @theme.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants