Bright/strong colors for high contrast under Annotation

[lindheli]

Under Annotation, the colors to choose between are all very soft. Would it be possible to add bright/strong colors for higher contrast as well? We also suggest adding black.

[danielweck]

CC @JayPanoz (ReadiumCSS wizard / maintainer) and @llemeurfr (EDRLab, Thorium "product owner", ultimately the arbiter of all design decisions / developement priorities) and @HadrienGardeur (also involved in the annotations / colours debate)

Thank you for your suggestion. I think we all absolutely agree on principle that ideally the contrast levels should be consistently high regardless of colour themes (publisher styles and reading app / user overrides), but we made pragmatic implementation choices.

For example the current colour palette was created from a limited set of named colours. Actual hues can vary slightly across RS / Reading Systems, but the symbolic names are to be standardized for interoperability purposes. This is to be proposed as a basis for a revision/update of the W3C annotations specification.

Plus, the availability of colour themes vary from one RS to another. For example Thorium doesn't support Windows-native system-level high-contrast themes yet, but this could be a new variable to adjust for when offering colours for highlights.

Note that highlights are used for annotations, search results, TTS (and to some extent EPUB3 Media Overlays synchronised text-audio too).

So, this is to be discussed further. I am moving this to a GitHub discussion.

[danielweck]

Also see: #2817

[danielweck]

@lindheli do you have a screenshot of a colour palette that would work for you? (maybe from other reading systems)

[llemeurfr]

There are two levels of discussion here.

1. Our designer chose the initial colour palette after some research. During the discussion on the export/import of annotations, we decided to limit the possibilities to 6 values, representing a union of those found in well-known reading systems. Adding more values to this list would be cumbersome for most users.
2. As Daniel said, we could make so that in certain conditions (= high contrast chosen at system level), these colors (yellow, green, blue ...) appear stronger.

I like this solution because it does not add any complexity to the user interface, and the UX adapts itself to the context of use of the app.

[danielweck]

I noticed that this issue was "locked" by GitHub earlier on, when I attempted to convert this to a "discussion" (GitHub crashed several times in a row, so I gave up in the end ;)

[danielweck]

Thank you Linda for sending this in:

"Here is a list of the colors to choose between in EasyReader, which is one of the current readers we recommend for our users, just for reference. This is not necessarily the best list of colors, just what our users are used to."

[JayPanoz]

ideally the contrast levels should be consistently high regardless of colour themes (publisher styles and reading app / user overrides)

As a side note, and I guess we will discuss that during the next engineering call, I‘ve started to give this a look in Playground + ts-toolkit, specifically the high-contrast issue, and there are some interesting problems to solve, or at least multiple strategies to implement with caveats.

Note CSS now has a color-mix() functional notation that gives an idea of how complex things can become re. color support.

[danielweck]

On this topic:

• https://lea.verou.me/blog/2024/contrast-color/
• https://blackorwhite.lloydk.ca

In Thorium's highlighting engine I attempted to use fancy CSS, but Chromium broke things in very interesting ways (Electron updates, as well as mainstream evergreen Chrome), so I opted for a much simpler contrast ratio calculation:

@supports (color: oklch(from red l c h)) { 
        background-color: rgb(R, G, B);

        color: oklch(from rgb(R, G, B)) clamp(0, (0.7 / l - 1) * infinity, 1) c h);
}

@supports (color: oklch(from color-mix(in oklch, red, tan) l c h)) {
        background-color: rgb(R, G, B);

        color: color(from rgb(R, G, B) xyz-d65 clamp(0, (0.36 / y - 1) * infinity, 1) clamp(0, (0.36 / y - 1) * infinity, 1) clamp(0, (0.36 / y - 1) * infinity, 1));
    }
}

@supports (color: contrast-color(red)) {
        background-color: rgb(R, G, B);

        color: contrast-color(rgb(R, G, B));
    }
}

===>

const calcRGB = (rgb: number) => {
    return (rgb <= 0.03928) ? rgb / 12.92 : ((rgb + 0.055) / 1.055) ** 2.4;
};
const computeHighContrastForegroundColourForBackground = (r: number, g: number, b: number) => {
    let foregroundColour = "#ffffff";
    const red = calcRGB(r);
    const green = calcRGB(g);
    const blue = calcRGB(b);
    // sRGB Luma (ITU Rec. 709) https://en.wikipedia.org/wiki/Rec._709
    const luminance = 0.2126 * red + 0.7152 * green + 0.0722 * blue;
    const pickBlack = (luminance + 0.05) / 0.05;
    const pickWhite = 1.05 / (luminance + 0.05);
    if (pickBlack > pickWhite) {
        foregroundColour = "#000000";
    }
    return foregroundColour;
};

[danielweck]

Regarding the Chromium breakage, see screenshots:

#2586

...see issue tracker:

https://issues.chromium.org/issues/371224775

...initially reported at Lea Verou's website:

LeaVerou/lea.verou.me#70

[HadrienGardeur]

As Daniel said, we could make so that in certain conditions (= high contrast chosen at system level), these colors (yellow, green, blue ...) appear stronger.

I'm always a little wary of meeting user needs strictly through system level settings. They're good for defaults and "auto" values, but it's best to allow the user to set things up in the app as well. FYI, this is consistent with both Thorium's approach for language and app theme.

IMO highlight colors should be theme-specific and at least for high-contrast themes, we should target a higher contrast ratio.

With our recommended approach for standardizing annotation colors, we're not using these strings (blue, yellow…) in the same way than in CSS. This means "any blue", "any yellow" etc. with sufficient contrast for a given theme.
This even means that if I have a blue background and cannot provide a highlight color with sufficient contrast using another shade of blue, then we'll need to display another color instead potentially.

We've also been discussing with @JayPanoz how we could automatically calculate high contrast colors to allow developers and users who set their own themes to always get good contrast on both text and highlights.

[JayPanoz]

We've also been discussing with @JayPanoz how we could automatically calculate high contrast colors to allow developers and users who set their own themes to always get good contrast on both text and highlights.

Issue in Playground with some references. I'd be happy this is moved to another place if it makes sense so that it can be easier to find for all maintainers and contributors across projects – in that case please feel free to edit the original post to better introduce the issue we are trying to solve.

[danielweck]

GitHub had a known bug (now fixed) when I tried to convert this to a discussion. I am trying again...