bug: countdown and radial-progress break Content Security Policy (require 'unsafe-inline' in style-src)

[eagle-head]

Reproduction URL

https://github.com/eagle-head/drink_water (branch feat/csp-level3-strict)

What version of daisyUI are you using?

v5 (latest)

Which browsers are you seeing the problem on?

All browsers

Describe your issue

What happens

The countdown and radial-progress components require values to be passed via inline style attributes:

<span style="--value:99;">99</span>
<div class="radial-progress" style="--value:70;">70%</div>

When a Content Security Policy is active with style-src 'self' (without 'unsafe-inline'), these inline style attributes are blocked by the browser (MDN reference). This forces applications that use these components to add 'unsafe-inline' to style-src, weakening the CSP.

Why this is not a DaisyUI design flaw

DaisyUI is a CSS-only library, and style="--value:X" is the natural way to pass dynamic values to CSS custom properties today. The CSS specification simply doesn't yet offer a cross-browser alternative for reading arbitrary data from HTML attributes into custom properties.

The ideal solution — attr(data-value type(<number>)) from CSS Values Level 5 — would allow reading data-* attributes directly into CSS custom properties without inline styles. But browser support is very limited:

CSS Feature	Chrome	Firefox	Safari
attr() with type (MDN)	133+ (Feb 2025)	Not implemented (bug open since 2008, part of Interop 2026)	No known support
@property (MDN)	85+	128+	15.4+

Until attr() with type is cross-browser, a pure-CSS solution isn't viable.

Proposed approach: data-value attribute with a small JS bridge

Add an optional data-value attribute that a small JavaScript snippet reads and applies via the DOM style API (element.style.setProperty()), which is explicitly allowed by CSP:

"Style properties that are set directly on the element's style property will not be blocked, allowing users to safely manipulate styles via JavaScript."

<!-- CSP-safe alternative (new) -->
<span class="countdown" data-value="99">99</span>
<div class="radial-progress" data-value="70" role="progressbar">70%</div>

The existing style="--value:X" API would remain for backward compatibility. When attr() with type reaches cross-browser support, the JS bridge can be replaced with pure CSS, and data-value would still work as-is.

Scope

Only 2 of 58 components are affected (countdown and radial-progress). All other DaisyUI components set custom properties internally via CSS classes — they are already CSP-compatible.

Why it matters

• CSP Level 3 is a W3C security standard to mitigate XSS attacks
• Compliance frameworks (PCI DSS, SOC 2, HIPAA) increasingly require strict CSP
• Frameworks are adding built-in CSP support: Phoenix/Elixir (in progress), Rails, Django (already ship with nonce support)
• Their ecosystems expect CSS libraries to be CSP-compatible

Reproduction steps

1. Clone eagle-head/drink_water
2. Checkout branch feat/csp-level3-strict
3. Run mix phx.server
4. Open /dashboard in the browser
5. Check logs/csp_violations.log for style-src-attr violations from countdown/radial-progress

Source code references

• radialprogress.css — reads var(--value) set via inline style
• countdown.css — same pattern

I'd like to contribute

I'm happy to submit a PR with the data-value JS bridge if this approach sounds good. The change is small and backward-compatible.

[github-actions]

Thank you @eagle-head for reporting issues. It helps daisyUI a lot 💚
I'll be working on issues one by one. I will help with this one as soon as a I find a solution.
In the meantime providing more details and reproduction links would be helpful.

[eagle-head]

Thanks for the feedback, @pdanpdan. I completely understand the concern — adding JS to a CSS-only library is a significant philosophical trade-off, and I raised that explicitly in the issue description.

I noticed a 👎 reaction but no comment — if there's a technical concern I'm missing, I'd appreciate hearing it so I can adjust the proposal or learn from it.

Given daisyUI's CSS-only identity, would any of these alternatives be welcome?

1. Documentation-only: Add a short note in the countdown and radial-progress docs explaining the CSP limitation and showing a copy-paste JS snippet users can add to their own projects.
2. Wait for attr() with type: It's part of Interop 2026, so cross-browser support may land this year. Once it does, data-value could replace inline style with pure CSS — no JS needed.
3. Out of scope: If this simply doesn't belong in daisyUI, that's a valid answer too. I can publish the workaround as a standalone gist/package for anyone who needs strict CSP.

@saadeghi — would love your take on this when you get a chance.

Happy to contribute whichever path makes sense for the project — or to close this if it's a "won't fix". Just let me know.

[saadeghi]

Thanks for the issue,
And thanks for all the details @eagle-head 🫡

• Documentation-only: Add a short note in the countdown and radial-progress docs explaining the CSP limitation and showing a copy-paste JS snippet users can add to their own projects.

We can't have a copy-paste JS snippet because daisyUI must work with or without JS, with any JS framework. And each JS framework has its own syntax and methods for reactivity. A JS snippet that works for Svelte won't work for React. Not to mention that there are countless JS frameworks out there.

• Wait for attr() with type: It's part of Interop 2026, so cross-browser support may land this year. Once it does, data-value could replace inline style with pure CSS — no JS needed.

This would be the optimal option, but it's too soon (as you mentioned). Safari and Firefox are not ready yet.

Out of scope: If this simply doesn't belong in daisyUI, that's a valid answer too. I can publish the workaround as a standalone gist/package for anyone who needs strict CSP.

I think it's important to acknowledge that this is not a default experience for the developers nor for the users. I think if CSP is being modified voluntarily, the side effects must be considered.

For example, I might decide to disable JS on my browser, but I won't expect all websites to be functional afterwards 😅

In this case, the styles can be customized to fit the goal, until a CSS-only solution gets a wider support by major browsers.
To customize the style, you can add custom styles to your CSS, or you can use utility classes, or you can exclude a component and use custom version of it.

Let me know if you have any questions.

[eagle-head]

Thanks for the thoughtful response, @saadeghi.

That all makes sense — I agree that CSP is a voluntary choice and the trade-offs are on the developer's side. The exclude + custom component approach is a clean solution for those of us who need strict CSP.

Looking forward to attr() with type landing across browsers — that'll be the best of both worlds.

Thanks for taking the time to explain the reasoning. Closing this one. 🙏