Off-the-rack night theme

[JayPanoz]

We’re very likely to ship with a “standard” theme for night mode. There are a couple of issues we must deal with, especially as it is a11y-related. In other words, we can probably make a few compromises but authors will have to make the most.

In the spirit of issue #5, I’d like to kickstart the conversation way ahead of time.

The current situation

The sad truth is that nobody knows how to deal with that.

• Invert/High contrast modes at the Operating System Level use a global filter (Windows | Mac).
• MacOS/iOS are not a global setting but a list of independent settings e.g. you can invert colors and use monochrome, and then add high contrast.
• Google has had a hard time implementing high contrast mode in Chrome.
• Reader Modes usually get rid of authors’ CSS so they don’t even have to deal with the related issues.
• Reading Systems sometimes use a global filter as well, sometimes try to do it via CSS.
• Kindle is normalizing colors and enforcing sufficient contrast ratio when converting EPUB files to KFX (+ font-family and font-size by the way)

Major issues

• Night mode ≠ white on black: it can be white on dark grey, it can be #FCFCFC on #121212, etc.
• Images: when there are a lot and they have a white background, night modes becomes useless. And we don’t know which images to invert, we can’t even rely on the format. There is some stuff I can manage with, say, 95% confidence (epub:type title page + image) though.
• SVG: even more complex than images.
• Backgrounds: figures, asides, etc. are complex to manage, especially as there are CSS hacks out there (using a linear-gradient + -webkit-text-fill-color for text). There’s also text on background images which we’d better not override if we don’t override background-image (JS territory).
• Borders: what do do of black borders, borders for which the color doesn’t provide sufficient contrast, etc? And we can’t check the color for the border’s element in pure CSS, that’s JS territory.
• Colors: contrast is an issue, especially when night mode is used as an a11y tool. Once again, the -webkit-text-fill-color hack might be used to enforce links’ or headings’ color.
• Gaiji i.e. a character that is valid in a given writing system, but that is not included in the present font and/or the present character encoding, and which therefore is displayed using an image, which we must invert at any cost necessary (and we can’t do p > img). iBooks had to create a metadata for that.
• Performance: if we have to check every element in the DOM, it will kill performance. Once again, this is something for which I wish we had Houdini (at 97% support).

Design

At first sight:

• Will override background-color and border-color but not background-image;
• Will override color but not -webkit-text-fill-color;
• Won’t invert images, and this is why I’m pushing for a mechanism so that authors can signal some images must be inverted. It could be ARIA territory (cc @rdeltour) since it also impacts high-contrast mode in nasty ways (cf. google issues in Chrome implem);
• SVG is a tough one, especially if the background is transparent and the author is not using currentColor for fill (can check some SVG attributes and the colors but it will result in insane CSS selectors);
• We must find something for gaiji; the fact iBooks and Kindle bothered implementing specific mechanisms to deal with it kind of show this is critical;
• Performance is @danielweck’s territory. I can find clever ways to deal with some overrides but for the complex ones, we can’t do without computed styles.

Possible issues this will create

• RSs stand in the first line so they will take the heat if users complain, especially if other RSs manage night mode the way the user wishes;
• Since there is no real “standard” in managing night mode, I can’t even tell what the users’ expectations are;
• Some authors will probably complain about color and stuff (but it’s an accessibility issue);
• Some others will point out alternate stylesheets exist (but it doesn’t solve the issues for the millions of files out there).

[JayPanoz]

Please note this is related to personalization:

• Personalization Semantics
• Draft of user settings, a section which has not beed addressed yet
• PWG Personalization Task Force Minutes (July 27)

[JayPanoz]

For gaiji, we’ll take the Japanese EPUB profile as a reference: http://ebpaj.jp/cmspage/wp/wp-content/uploads/2015/04/ebpaj_epub3guide_ver1.1.3-en-1.zip

[JayPanoz]

An interesting idea from Wikipedia that we might implement as well, especially as it is one line of CSS: letting the user darken all images in night mode (sorry, screenshot in french)

In that case, having another switch for inverting all images could be offered as well, it may be unperfected but for some books, it could solve a lot of issues (headings or table as images, B&W illustrations, etc.).

[rdeltour]

Won’t invert images

I think it's a safe approach. In the vast majority of cases, images should not be inverted.

and this is why I’m pushing for a mechanism so that authors can signal some images must be inverted. It could be ARIA territory (cc @rdeltour) since it also impacts high-contrast mode in nasty ways (cf. google issues in Chrome implem);

An author-defined mechanism might be interesting. The right venue to ask for feedback/interest could be WICG.

Another approach, as you state in you last comment, is to have a user preference. But "coloring" and "inverting" should be kept separated IMO. People could want the image to be darkened, or be applied a sepia filter, but still don't want to be inverted in a full night mode.

[JayPanoz]

But "coloring" and "inverting" should be kept separated IMO. People could want the image to be darkened, or be applied a sepia filter, but still don't want to be inverted in a full night mode.

Sorry if it was unclear, darken and invert would be 2 different switches, obviously (this is how I implemented them yesterday BTW).

For the record:

• darken uses filter: brightness()
• invert uses filter: invert()

As for sepia, we currently apply a mix-blend-mode by default so that white backgrounds are sepia—that may change in the future. Unfortunately filter: sepia() has way too much impact on colors when it comes to photos.

Thanks for the feedback!

[JayPanoz]

As an update, I did a quick round of testing today and night mode is quite alright. Darken and invert options definitely help, they can improve comfort pretty dramatically in some illustrated-heavy publications.

Haven’t had the time to check everything yet but that’s a good start, we don’t have any major issue to deal with.

[JayPanoz]

After further testing, we’d probably better create some kind of CSS inverted variable implementers can use.

The assumption is:

• we have styles which sole purpose is applying the night mode (their reusability is null at the moment, and that doesn’t philosophically fit that well in our design approach);
• users are currently able to override it (applying night mode then setting their own background and text color in advanced settings);
• the night theme stylesheet could be used to manage all inverted modes (custom colors set by the user);
• invert state can be interpolated from the custom background-color (it’s a range in rgba?);
• theme variables could become user variables with a fallback;
• themes would therefore become part of user settings, and would be appended on load (no extra stylesheet necessary).

Benefits for implementers:

• night modes (plural) from the same stylesheet;
• inverting images could use a dynamic factor (variable), based on the colors picked by the user (which means it can also be 0 to not invert images if needed);
• sepia could be adopting this approach as well (for pastel backgrounds, which would be useful in terms of a11y);
• extra flexibility.

On the other hand, we should probably start discussing a fallback mechanism for browsers which don’t support CSS variables. Although we’re not impacted with the reference implementations (iOS + Readium Desktop), some implementers will have to deal with IE11 and Edge 14 (web app).

I can open a dedicated issue now but feedback from implementers will come later, obviously (it needs practical implementations to see which options are the best ones).

[JayPanoz]

Closing this issue since we’re past design and it should be now managed on an issue-by-issue basis.

As an update, handling of OSs’ invert setting (a11y) has been improved a little bit (must still do extended testing).

Last comment I posted should be a (new) specific issue as well, since it is not about the night mode per se but re-usability of the sepia and night mode modules.