EPaper: eine Web-Component-Bibliothek für E-Paper-Displays

E-Paper-Panels hebeln mehrere Annahmen aus, auf denen übliche Komponentenbibliotheken aufbauen: Refresh-Zeiten liegen im Bereich mehrerer hundert Millisekunden, Touch-Panels melden keinen Hover-Zustand, und die Zahl der stabil darstellbaren Tonwerte ist gering. Ein Theme über einer etablierten Bibliothek kann diese Annahmen nicht zurücknehmen; EPaper ist deshalb eine eigene Web-Component-Bibliothek für elektrophoretische Displays: gut achtzig Custom Elements mit dem Präfix e-, ohne Framework, ohne Laufzeit-Abhängigkeiten, unter MIT-Lizenz auf npm.

Refresh-Verhalten und DOM-Updates

Animationen und CSS-Transitions werden im globalen Stylesheet deaktiviert, da die Refresh-Charakteristik von E-Paper-Panels sonst zu deutlichem Ghosting führt, das auch mehrere folgende Refreshes überdauert. Dieselbe Überlegung betrifft die Render-Strategie: Wird ein Teilbaum ersetzt, plant der Display-Controller einen vollen Panel-Refresh ein, der rund 200–800 ms dauert und sichtbar aufblitzt, während die Änderung eines einzelnen Attributs oder Textknotens einen partiellen Refresh im Bereich von 30–80 ms auslöst.

Komponenten rendern deshalb einmalig beim Einhängen in das Dokument und wenden danach gezielte DOM-Mutationen über wenige typisierte Hilfsfunktionen an. Diese brechen ab, wenn sich der Wert nicht geändert hat — eine Komponente innerhalb eines reaktiven Frameworks löst damit keinen Repaint aus, wenn das Framework bei jedem Render-Durchlauf dasselbe Attribut erneut setzt.

Zustände ohne Hover und ohne Transparenz

Da E-Paper-Touchflächen bauartbedingt kein Hovering unterstützen, werden Interaktionszustände anders abgebildet: Fokus als 3px-Outline mit 2px Abstand, der gedrückte Zustand über eine Invertierung von Vorder- und Hintergrund, Auswahl über eine flache Füllung. Deaktivierte und fehlerhafte Zustände nutzen Diagonalschraffuren, die einmal als Design-Token definiert sind.

Transparenz und Grautöne werden zur Zustandsdarstellung bewusst vermieden. Zwischentöne werden vom Controller gedithert, und das Dither-Muster ist zwischen zwei Refreshes nicht stabil, sodass ein mit reduzierter Deckkraft gestaltetes Element bei jedem Repaint seine Textur ändert. Farbe steht auf monochromen Panels ohnehin nicht zur Verfügung.

Formularfähigkeit und DOM-Modell

Alle interaktiven Controls — Eingabefelder, Checkboxen, Radio- und Checkbox-Gruppen, Schalter, Auswahllisten, Cascader, Tree-Select, Zahlenfelder, Datums- und Zeitauswahl sowie Upload — sind formularfähige Custom Elements auf Basis von ElementInternals. Mit einem name-Attribut nehmen sie an FormData, form.reset() und der Constraint-Validierung teil, ein Formular verhält sich also ohne zusätzliche Event-Handler oder State-Verwaltung korrekt. Für Kiosk-Installationen, bei denen die Anwendung häufig aus einer einzigen HTML-Datei besteht, ist das der relevante Punkt.

Die Komponenten rendern in das Light DOM statt in einen Shadow Root. Das hält die Formularteilnahme unkompliziert, erlaubt das Überschreiben von Styles mit gewöhnlichen CSS-Selektoren und umgeht die Shadow-DOM-Defekte in den reduzierten Browser-Builds, die auf solchen Geräten oft ausgeliefert werden. Im Gegenzug gehören das gerenderte Markup und seine .ink-*-Klassennamen zur öffentlichen API.

Geometrie und Typografie

Die Strichstärken richten sich nach den physikalischen Eigenschaften der Panels. Bei 150–300 ppi und ohne Subpixel-Antialiasing verlieren 1px-Linien an Kontrast, weshalb die Standard-Rahmenbreite 2px beträgt und Haarlinien reinen Trennelementen vorbehalten bleiben. Icons sind mit 2px Strichstärke, eckigen Enden und spitzen Ecken sowie ohne Flächen gezeichnet, da runde Endpunkte und kleine gefüllte Flächen sichtbare Refresh-Artefakte erzeugen.

Touch-Ziele sind standardmäßig 44px hoch, was bei 300 ppi etwa 3,7 mm physischer Fläche entspricht — ein praktisches Minimum, weil kapazitive Schichten über E-Paper ungenauer arbeiten als über OLED. Die Zeilenhöhe liegt bei 1,55 für Oberflächentext und 1,6 für längeren Fließtext, der in einer Serifenschrift gesetzt ist, da reflektierende Graustufendarstellung langsamer gelesen wird als ein hinterleuchtetes Display. Auf Kaleido-Panels werden die fünf verfügbaren Farben als flache Tokens bereitgestellt, nicht als Verläufe oder Alpha-Überlagerungen; eine Diagnose-Komponente stellt jede Farbe neben ihrer geditherten Vorschau dar, sodass sich das Ergebnis auf der Hardware schon im Entwurf beurteilen lässt.

Auslieferung

Das CSS besteht aus drei Schichten — Tokens, Reset und Komponenten-Styles — und liegt sowohl als lesbare Quelle für Bundler als auch als kombiniertes, minifiziertes Bundle mit rund 5 KB gzip vor. Der vollständige Komponentensatz liegt bei etwa 42 KB gzip; Subpath-Imports pro Komponente reduzieren das in der Praxis. Typdeklarationen, ein Custom Elements Manifest und IDE-Metadaten für VS Code und JetBrains entstehen im Build. Dokumentation, Beispiele und Storybook stehen auf epaper-components.dev, der Quellcode liegt auf GitHub.