Try to cleverly handle contrast in the theming context

[JayPanoz]

Theming (#73) implies the user can style as they wish so we should try to handle contrast (WCAG) in a clever manner. This ends up impacting highlights as well (#65) and means revisiting this comment in a closed issue.

---

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.

---

Interesting links:

• https://css-tricks.com/css-variables-calc-rgb-enforcing-high-contrast-colors/
• https://css-tricks.com/methods-contrasting-text-backgrounds/
• https://css-tricks.com/reverse-text-color-mix-blend-mode/

If anything those experiments show it’s possible with CSS, but need to be tested to see whether an option can be deemed production-ready, similar to what we did for dyslexia-related features in the past.

[JayPanoz]

Note it’s also something that should be predictable for implementers, so inverting through blend modes and CSS filters don’t look like an option. Then the question is whether calc requires strict values (rgb, etc.) that aren’t flexible enough for them – but this applies to highlights as well so it’s about “opinionation”.

[JayPanoz]

So this has been resolved during today’s engineering call.

It may be better if the app helps the user choosing background and text color.

So as an action item, docs should be updated to make it clear to implementers.