bug: `card-title` sets its own (incorrect) text `color`

[AtmoFX]

What version of FlyonUI are you using?

2.4.1

Which browsers are you seeing the problem on?

All browsers

Reproduction URL

https://play.tailwindcss.com/a4Rs3y7iVO

Describe your issue

The image overlay example, in e.g. theme Spotify, has a not-so-easy-to-read white text (forced with text-white class).

One may think we can just remove text-white and it works, but not for the title as .card-title has the rule: color: var(--color-base-content);.

According to doc, the card-title h2 is a descendent of the card-body div, which has the (correct) text color set on it. As a result, it would be more convenient (more correct?) for card-title to simply inherit the text color from its card-body ancestor.

[github-actions]

Hi @AtmoFX

Thank you for your support in helping us improve FlyonUI!

We’ve received your submission and will respond within few business days. Our team handles issues one at a time, and we’ll be reviewing yours as soon as possible.

In the meantime, any additional details or a reproducible example would be greatly appreciated and will help us resolve the issue more efficiently.

Thank you for your patience and understanding!

[PruthviPraj00]

Hello @AtmoFX,

Below is the basic structure of the card:

<div class="card sm:max-w-sm">
  <div class="card-header">
    <h5 class="card-title">Exclusive Feature Highlight</h5>
  </div>
  <div class="card-body">
    <p>
      Discover the unique benefits and features we offer. Dive deeper to learn how our solutions can enhance your experience and meet your needs effectively.
    </p>
  </div>
</div>

With this layout, the card-header can not inherit the text color from the card-body. The card-body uses the secondary body color (text-base-content/80), which is intended for regular content text, while the card-title uses the default heading color (text-base-content).

If needed, you can always override the text color of the card-title explicitly.

I hope this clarifies things and answers your question.

[AtmoFX]

This example is irrelevant though. And my point is not about being able to override the text color either, it is about avoiding having to.

The specific paragraph I have copied and linked from the flyonui website was "Image overlay" (https://flyonui.com/docs/components/card/#image-overlays). Be sure to check the repro link I provided is a perfect copy/paste of the code from your site + what happens when removing the forced text color.

There is no div.card-header in that snippet; neither is there, BTW, in:

• the first "Basic" example (Default) at the very top of the page
• the regular "Image" example (https://flyonui.com/docs/components/card/#image)
• the "Title text and links" example (https://flyonui.com/docs/components/card/#image)
• the "Card footer" example (https://flyonui.com/docs/components/card/#card-footer)
• And more...

So, yes, you sure can find a few cases that follow the structure you are giving me, but that is in fact the minority of what I find of the page.
Among these, image overlay comes different because the image gets a light filter on it, requiring the text color to be set to --color-neutral-content (blackish), whereas other cases are on the regular dark background, hence --color-base-content (whitish) is suitable.

For reference, taking that basic structure you are giving me and turning it into an "image overlay" card results in a complete mess of a card (the body is pull up to cover the header)

To reconcile the 2 points, I would recommend to leave the text color to the following rule:

.card {
  &.image-full {
    & > .card-body {
      position: relative;
      color: var(--color-neutral-content);
    }
  }
}

Which means, the rule that is causing me issues (below) should have a :not(.image-full) somewhere, so that it does not conflict.

  .card-title {
    font-size: var(--text-2xl);
    line-height: var(--tw-leading, var(--text-2xl--line-height));
    --tw-font-weight: var(--font-weight-semibold);
    font-weight: var(--font-weight-semibold);
    color: var(--color-base-content);
  }
}

Alternatively, the text color could perhaps be left to the parent div.card-header instead of the inner div.card-title, but like I pointed out, many of the provided snippets do not come with one, so the color of the entire card would be inherited from the .card parent.
Going this way, cases that do not have a div.card-header will have to settle for inheriting text-base-content/80.

[PruthviPraj00]

Thank you for the detailed investigation and for suggesting a very helpful solution.

Yes, card-title can be used inside both' card-header' and' card-body', but it should not inherit its color from either.
The title is treated as a heading element, and its color is defined intentionally to maintain a clear visual distinction from regular body text, regardless of where it is placed within the card.

Given our current implementation of image-full, we agree that the best improvement is not to remove the explicit color from .card-title, but to define the correct semantic colors for image overlays directly in the component CSS.

Currently, image-full sets:

> .card-body {
  @apply text-neutral-content relative;
}

This applies the same color to both body text, but it does not update the card-title.

To improve this, we’ll update the image-full styles so that:

• Body text uses text-neutral-content/80
• Card title (heading) uses text-neutral-content

This keeps:

• Proper visual hierarchy (title stronger than body)
• Full theme compatibility (no hardcoded text-white)
• No need for users to manually override text colors

Proposed update:

&.image-full {
  @apply grid;

  &:before {
    @apply bg-neutral rounded-box relative col-start-1 row-start-1 opacity-75;
    content: "";
  }

  > * {
    @apply col-start-1 row-start-1;
  }

  > .card-body {
    @apply text-neutral-content/80 relative;
  }

  > .card-body > .card-title {
    @apply text-neutral-content relative;
  }

  :where(figure) {
    @apply overflow-hidden;
    border-radius: inherit;
  }

  > figure img {
    @apply h-full object-cover;
  }
}

We’ll also update the Image Overlay example in the docs to reflect this behavior, so users don’t need to add manual color utilities.

If you’d like to open a PR with this change, we’d be happy to review it. Contributions are always welcome ❤️