@apply doesn't comprehend the idea of custom mixins

[KTibow]

What version of Tailwind CSS are you using?

tailwindcss and @tailwindcss/vite 4.1.17

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

Vite 7.2.7

What version of Node.js are you using?

v24.10.0

What browser are you using?

Firefox/Chromium

What operating system are you using?

Linux

Reproduction URL

https://play.tailwindcss.com/jrsuOy41LK?file=css

Describe your issue

@apply is from the functions and mixins module; if I apply something Tailwind doesn't know, especially when it begins with --, Tailwind should pass it through untouched so either the browser can render it or any compat logic I have on top can work.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and agent prompts for this issue.

• Create Plan

Examples

• Example 1
• Example 2

🔗 Similar & Duplicate Issues

Related Issues

• tailwindlabs/tailwindcss#18058
• tailwindlabs/tailwindcss#17990
• tailwindlabs/tailwindcss#19127
• tailwindlabs/tailwindcss#19117
• tailwindlabs/tailwindcss#18139

👤 Suggested Assignees

• andreww2012
• slingshotsys
• helpimnotdrowning
• ace-of-aces
• arackaf

---

🧪 Issue enrichment is currently in early access.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

[undefinedIsMyLife]

I’m running into an issue with @apply being overly strict when the applied token isn’t a known Tailwind utility specifically when using custom-property-based utilities that begin with --.

Example:
.button {
@apply --my-custom-util;
}

Since --my-custom-util isn’t a Tailwind utility, Tailwind currently throws an “unknown utility” error. But because@applycomes from the functions/mixins layer, it would be helpful if unknown tokens especially those starting with -- were simply passed through untouched rather than causing the build to fail.

Expected behavior:
Tailwind expands known utilities within @apply.
Unknown tokens (particularly --*) are preserved as-is so that user-defined tooling, browser logic, or postprocessing steps can handle them.

This would allow better interoperability with custom properties, design systems that generate their own utility-like tokens, and progressive enhancement workflows.

If needed, this could be behind a config flag (e.g., a loose mode), but even special-casing --* would solve the issue without introducing risk.

Happy to help with a PR if this approach is acceptable!

[thecrypticace]

This has been on my list to look at for a bit. The spec didn't have the details filled in for @apply yet when I last checked (it was still up in the air afaik) but it looks like it has since updated.

[thecrypticace]

So we can fix this in Tailwind CSS so it doesn't error however Lighting CSS does not support mixin syntax right now so production builds won't work right unless you disable optimization.