theme.colors
If you define colors directly under
theme.colors
(instead of
theme.extend.colors
),
you
lose all default Tailwind colors
.
bg-custom-destructive
):
bg-blue-500
):
Comment: Notice how
bg-blue-500
does not apply. This is because the entire default color palette was replaced by only
custom-destructive
and
custom-safe
.
(To properly demonstrate the "correct" way below without page reload or complex JS, we're using a conceptual separation. In a real scenario, you'd have one correct config from the start.)
theme.extend.colors
When you use
theme.extend.colors
, your custom colors are
added alongside
Tailwind's default color palette. This is usually what you want.
bg-brand-cta
):
bg-indigo-500
):
Comment: Here, both our custom color
bg-brand-cta
and the default
bg-indigo-500
are applied correctly because we used
theme.extend.colors
. This preserves the default palette while adding our customizations.
The Tailwind CSS CDN typically processes one
tailwind.config
object. When multiple are present in
<script>
tags,
the behavior (which one takes precedence or if they merge) can be unpredictable or version-dependent.
This example uses two separate conceptual blocks to illustrate the *effect* of overriding vs. extending.
In a real project, you would have only
one
configuration, correctly using
theme.extend.colors
to avoid losing default styles. The "Incorrect Way" shown above is for demonstration of the pitfall only.
For the "Correct Way" to render accurately in this standalone file after the "Incorrect Way" config, the Tailwind JIT might need a re-initialization, or the second config might take over. The key takeaway is the *conceptual difference* in configuration structure.