How should we handle author-defined text colors in reading modes and themes?

[JayPanoz]

This issue originally appeared in the readium-js issue tracker but ReadiumCSS is impacted as well.

We’re currently aligned with iBooks and treat color overrides pretty much in the same fashion for sepia and night modes (heavy usage of !important in night mode to force the color of links or svg text, something we don’t do for sepia mode since it can be treated as the day mode).

Sepia mode: https://github.com/readium/readium-css/blob/develop/css/src/modules/ReadiumCSS-sepia_mode.css Night mode: https://github.com/readium/readium-css/blob/develop/css/src/modules/ReadiumCSS-night_mode.css

However, we’ll have themes (and custom user colors) in the beta, and things will become tricky.

In anticipation of themes a few months ago, I fantasized sepia and night modes being redesigned as light and dark modes themes (and custom user colors) can actually reuse, but that’s easier said than done.

Indeed, it is not rare apps offer a light blue or mint background, possibly for a11y reasons (pastel backgrounds may help with dyslexia, color blindness, or vision problems for instance) and that can’t work as in sepia mode:

• blue links on a light blue background;
• red on a pink background;
• green/red headings on a mint background;
• #666 text on a gray background;
• etc.

So a light mode in which we don’t override colors wouldn’t work in those cases, it would probably be more like a “twilight/gloom mode”, in between light and dark.

[JayPanoz]

Note that we may want to define which elements are impacted in different scenarios and which should be overridden at any costs. But color being one of those properties you can use extensively for any element, it will be quite hard to target them precisely.