Overriding Daisy's Cally styling: not all color variables brought in ?

[PRoyLCB]

Hi all,

I wanted to override a bit the default colors that are set by Daisy for Cally's calendar, with the use of cally class.

I just did this:

<style>
/* Cally Calendar Theming */
calendar-month {
  /* make the weekend days lighter */
  &::part(button day-0) {
    color: color-mix(in srgb, currentColor 40%, transparent);
  }
  &::part(button day-6) {
    color: color-mix(in srgb, currentColor 40%, transparent);
  }

  /* change default hover on calendar dates */
  &::part(button):hover {
    background-color: color-mix(in srgb, var(--color-primary) 10%, transparent) !important;
  }

  /* change defaults for selected and today's dates */
  &::part(selected),
  &::part(selected):hover {
    background-color: var(--color-gray-600) !important;
  }
  &::part(today),
  &::part(today):hover {
    background-color: var(--color-accent) !important;
    color: var(--color-accent-content) !important;
  }
}
</style>

<div class="dropdown dropdown-bottom flex-1">
  <button
    tabindex="0"
    role="button"
    class="btn btn-sm w-full justify-start gap-2">
    <i class="fa fa-calendar"></i>
    <span x-text="selectedInvoice?.dueDate ? formatLongDate(selectedInvoice.dueDate) : 'Set due date'"></span>
  </button>

  <div tabindex="-1" class="dropdown-content my-1 p-2 bg-base-100 border border-base-300 shadow-sm rounded-box">
    <calendar-date
      class="cally"
      :value="selectedInvoice?.dueDate || ''"
      @change="handleCalendarChange($event)"
      locale="en-CA"
      first-day-of-week="0">

      <button slot="previous" class="btn btn-ghost btn-xs btn-square"> 
        <i class="fa fa-chevron-left"></i>
      </button>
      <button slot="next" class="btn btn-ghost btn-xs btn-square">
        <i class="fa fa-chevron-right"></i>
      </button>
      <calendar-month></calendar-month>
    </calendar-date>
  </div>
</div>

which renders something like;

That January 14th renders black, but it should have been daisy' default color-accent in theme "light":

--color-accent: oklch(77% 0.152 181.912)

If I inspect the calendar and look at the computed variables, they all seem (I think?) to be accurate, with the exception of that accent one:

* Looks like --color-accent is wrong, but --color-accent-content seems to be right!

If I inspect outside the calendar, then the accent IS at the right color.

Is this normal ? It almost looks like the accent color isn't brought it properly into the cally calendar (shadow dom is it?) and looks like a bug.

If anyone knows ? Am I customizing this the right way here?

MUCH thanks!

Regards,
Patrick

[LazycoderAayu]

Hi Patrick! Your DevTools screenshots confirm exactly what's happening: it's a Shadow DOM encapsulation issue.

In your first image (inside the calendar), --color-accent has defaulted to black, while your second image shows it works perfectly outside. This happens because the Shadow DOM boundary is losing the connection to the variables defined by DaisyUI on the :root or [data-theme] level.

Why this happens

Web components (like <calendar-month&gt;) use a Shadow DOM. While they should inherit CSS variables, if those variables are defined on a specific selector (like [data-theme="light"]) rather than the <calendar-date> element itself, the internal parts often struggle to resolve them and fall back to black.

The Fix

To ensure the variables "pierce" the shadow boundary, you need to explicitly map the DaisyUI internal variables to the .cally class. This makes them available directly on the component's "skin."

Try adding this to your CSS:

---

A cleaner way to override

Instead of using !important in your <style> block, define the inheritance specifically on the .cally class to force the Shadow DOM to look at the parent:

Pro Tip: Since your DevTools showed the value as "black" inside the component, applying the mapping above to .cally will replace that black fallback with the correct oklch value from your theme.

Hope this helps get that January 14th looking right! If this fixes the issue, feel free to mark this as the answer.

Would you like me to find another GitHub issue for you to tackle? You're doing great—Patrick is going to be very impressed with this detailed breakdown.