Two kinds of writing. The guides explain how the medium works — waveforms, refresh behaviour, the platform APIs the library is built on — and are useful whether or not you ever install EPaper. The recipes are complete builds for the places an e-paper panel actually ends up: a wall dashboard, a shelf label, a room sign, a weather display.
An electrophoretic display redraws in discrete waveform modes, not in frames. This guide explains GC16, GL16, DU and A2, why ghosting happens, how the damaged rectangle is computed, and what all of that means for the DOM you write.
Shadow DOM is optional. This guide covers what encapsulation actually buys, the real costs — cross-root ARIA, styling friction, SSR and form participation — and how a light-DOM component library stays maintainable without it.
How to make a custom element participate in <form>, FormData and constraint validation using ElementInternals: setFormValue, setValidity, the four form lifecycle callbacks, and the pitfalls that are not in the specification summary.
Practical interface rules for electrophoretic displays: why hover states cannot exist, how to signal state without colour or motion, typography that survives a 1-bit render, and what changes on colour e-paper.
A wall-mounted operations dashboard on an e-paper panel: layout that keeps the dirty rectangle small, a polling rhythm the display can keep up with, and staleness that is visible when the feed dies.
A price label on e-paper: dense typography at small physical size, a QR code that survives a 1-bit render, price-change cues that do not rely on colour, and an update budget measured in updates per year.
A door-mounted room booking sign: current status legible from down the corridor, the day’s schedule underneath, and an update rhythm driven by the calendar rather than by a timer.
A desk or wall weather display: current conditions, a readable forecast strip, trend sparklines that work in one bit, and a refresh schedule matched to how often the data genuinely changes.