Feature request: native dark mode
Current situation:
The editor currently only ships with a light theme. Applications with a dark UI need to manually override all internal Tailwind classes to achieve a dark appearance.
In our case (@eigenpal/docx-js-editor@0.4.1), we ended up with 200+ lines of CSS overrides targeting .ep-root internals like .bg-white, .bg-slate-100, .text-gray-900, borders, dropdowns, and more — all with !important to win specificity battles against the editor's own classes. This is fragile and breaks on every patch release that touches class names.
What we'd like:
A first-class theme prop (or a CSS custom-properties contract) that the editor respects internally:
```tsx
<DocxEditor theme="dark" ... />
// or
<DocxEditor theme={{ background: '#0f0f14', text: '#e4e4e7', ... }} />
```
Alternatively, exposing a set of CSS variables (e.g. --ep-bg, --ep-text, --ep-border) that integrators can override from the outside without touching internal class names would already be a huge improvement.
Why it matters:
Medical and professional tooling (our use case is a radiology report editor running 24/7) almost universally uses dark interfaces. Right now dark-mode support requires consumers to reverse-engineer the component tree and pin to exact Tailwind class names — making upgrades risky.
Workaround we're currently using (for reference):
We wrap the editor in a data-editor-theme="dark" attribute and target every internal class from outside — a classic "CSS injection" pattern that we'd love to drop.
Feature request: native dark mode
Current situation:
The editor currently only ships with a light theme. Applications with a dark UI need to manually override all internal Tailwind classes to achieve a dark appearance.
In our case (
@eigenpal/docx-js-editor@0.4.1), we ended up with 200+ lines of CSS overrides targeting.ep-rootinternals like.bg-white,.bg-slate-100,.text-gray-900, borders, dropdowns, and more — all with!importantto win specificity battles against the editor's own classes. This is fragile and breaks on every patch release that touches class names.What we'd like:
A first-class
themeprop (or a CSS custom-properties contract) that the editor respects internally:```tsx
<DocxEditor theme="dark" ... />
// or
<DocxEditor theme={{ background: '#0f0f14', text: '#e4e4e7', ... }} />
```
Alternatively, exposing a set of CSS variables (e.g.
--ep-bg,--ep-text,--ep-border) that integrators can override from the outside without touching internal class names would already be a huge improvement.Why it matters:
Medical and professional tooling (our use case is a radiology report editor running 24/7) almost universally uses dark interfaces. Right now dark-mode support requires consumers to reverse-engineer the component tree and pin to exact Tailwind class names — making upgrades risky.
Workaround we're currently using (for reference):
We wrap the editor in a
data-editor-theme="dark"attribute and target every internal class from outside — a classic "CSS injection" pattern that we'd love to drop.