fix(module): stop using tailwind's shorthand arbitrary variable syntax

[sandros94]

🔗 Linked issue

Resolves #2365

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

source: tailwindlabs/tailwindcss#13395 (comment)

[...] in v4, it will be max-w-[var(--breakpoint-sm)] as the shorthand arbitrary variable syntax will no longer be supported.

property-[--var-ref] ➞ property-[var(--var-ref)]

[...]

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[pkg-pr-new]

pnpm add https://pkg.pr.new/@nuxt/ui@2366

commit: 78b474a

[benjamincanac]

@sandros94 It seems you're missing some classes:

• text-[--ui-text-muted]
• text-[--ui-text-highlighted]
• ring-[--ui-border-accented]
• etc.

[sandros94]

It seems you're missing some classes:

Yeah, I though about it as soon as I got into bed 😅

I'm fixing them up right now

[sandros94]

@benjamincanac all fixed up

[benjamincanac]

I'm wondering if it would be a good idea to define all those as Tailwind CSS utilities.

Not exactly like before (https://github.com/nuxt/ui/pull/2298/files#diff-d57c48a7c2fad5e00150be2d599877390d949dd7409fb976099c0cd21a26971a) but something like this:

@theme default {
  --color-primary: var(--ui-primary);
  --color-secondary: var(--ui-secondary);
  --color-info: var(--ui-info);
  --color-success: var(--ui-success);
  --color-warning: var(--ui-warning);
  --color-error: var(--ui-error);

  --color-text-dimmed: var(--ui-text-dimmed);
  --color-text-muted: var(--ui-text-muted);
  --color-text-toned: var(--ui-text-toned);
  --color-text: var(--ui-text);
  --color-text-highlighted: var(--ui-text-highlighted);

  --color-bg: var(--ui-bg);
  --color-bg-elevated: var(--ui-bg-elevated);
  --color-bg-accented: var(--ui-bg-accented);
  --color-bg-inverted: var(--ui-bg-inverted);

  --color-border: var(--ui-border);
  --color-border-accented: var(--ui-border-accented);
  --color-border-inverted: var(--ui-border-inverted);
}

This would allow users to write text-primary / bg-primary / border-border / ...

We would keep the theme as-is with CSS variables so users choose to define the primary colors in their theme as described here it would be blocking.

What do you think?

[benjamincanac]

(We cannot write this index.css file dynamically as we import it from @nuxt/ui otherwise it would require to import from #build/ui.css which is less .)

[sandros94]

What do you think?

Not an easy decision 😅

Personally speaking I do enjoy the idea of being in full control of the tailwind's theme within the end project.
But we are talking about utilities that are used by the vast majority of the projects, so ask myself: "why not?"

Just a thought: if we do add those utilities, does it mean that we do need to always include the related css variables?

[sandros94]

Just an idea that I had:

Have multiple .css within the module. A default one that is used when doing @import "@nuxt/ui"; that does integrate the suggested @theme default, while also providing a @import "@nuxt/ui/minimal"; that mostly integrates the current index.css.

The module should be written and maintained with a css var approach (text-[var(--ui-color-primary)] instead of text-primary), making sure that both minimal and default work, but this approach would let module/layer authors to take full control, while also provide great out-of-the-box experience for non-advanced use cases.

P.S.: might also be useful to have a dedicated transition.css file

[benjamincanac]

This is a good idea! I'll keep thinking about this 😊