In case helpful, I noticed that my Firefox and Chromium (both latest, on Linux Mint) are displaying different colors from your screenshots above. So I'd guess these are partially OS-defined/overriden colors? (However, I have previously selected a "dark grey" theme for my Mint OS configuration, so I'm likely not seeing the 'defaults')

@Quiddity thank you for this! Interesting to see for sure. It feels like these combinations could almost be anything depending on many different parameters. Maybe the best path forward is to choose a logical option that feels relatively common, uses Codex color tokens, and isn't likely to be similar to another use of color in this way, i.e. any of the upcoming diff themes, etc. I will put together a proposal.

Change #1216852 had a related patch set uploaded (by Dtorsani; author: Dtorsani):

[design/codex@main] token: Add NEW Background Highlight Target Text color token

https://gerrit.wikimedia.org/r/1216852

I've got a patch up, and a demo where you can see my proposal. My proposal is this:

1. For now, we only customize the target text highlight, as this is the one that is more problematic and inconsistent.
   1. The most accessibility problems come in dark mode, when the highlight color is too light and the text remains white or when the highlight is too bright for dark mode.
   2. The selection text highlight is essentially the same blue across defaults which have not been customized or altered. For this reason, and because this one does not present any similar problems to the target text, let's not add a token for this/customize this.
2. We use orange50 for the target text highlight color, for the following reasons.
   1. Orange is the chromatic opposite than blue (the selection text highlight color in most audited defaults).
   2. Orange is similar to yellow, one of the common defaults for target text highlights.
   3. Orange is not currently being used for any other sort of highlighting of text, such as in the planned diff style theme updates T394117: [EPIC] Diff styling.
   4. No matter what color we would use, the 50 value must be used to ensure proper 4.5:1 color contrast with any Codex text color token that is meant to be read, including all link colors, both visited and non-visited, in both light and dark modes.
3. Based on 2B above, one might ask, "Then shouldn't we customize the selection text highlight color as well to ensure proper contrast?" At this time, we feel this is not necessary for the following reasons.
   1. Selection implies manual highlighting text that has already been read, and therefore does not necessarily, absolutely need to meet color contrast ratios when selected.
   2. This does not feel worth the change from the common default selection text highlight color to something then different from what people will see anywhere outside of any website using Codex.
4. The token is named background-color-highlight-target-text.

@JScherer-WMF @Jdlrobson-WMF Can you please review this proposal and provide your thoughts? If we feel good about this, or once we do, then @Catrope can do the final review and merge this into Codex, ready to be used onwiki after the next Codex release.

@DTorsani-WMF in terms of tokens I think matching browser terminology is a good idea.

So for manual:

• background-color-selection (https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::selection) and

For target highlight:

• background-color-target-text (https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::target-text)

I don't have any opinions around the colors. As long as they are accessible in dark mode I am happy (but FWIW if there's a hot pink option I would be very much for that).

I think I agree that maybe we don't need "highlight" in the token name. I think @Volker_E supports that as well.

Either way, in my proposal, we aren't customizing the selection color, and are going with orange for the reasons stated above.