[css-color-adjust-1] Emojis in forced colors mode

[alisonmaher]

Currently in forced colors mode, emojis are not adjusted (similarly to images).

For example, when using the following emojis: 🤞😡👍🎉❓🤷‍♂️👆👈🤔🔮🔍👻

Blink and Gecko will produce the following in a dark forced color scheme:

However, in EdgeHTML and most Windows apps, emojis will fall back to use a monochrome variant of the emoji colored in the Windows High Contrast text color (i.e. CanvasText):

The monochrome variant would provide higher levels of contrast and parity with how Windows generally handles emojis in High Contrast. Is this something we should consider recommending or aligning with in the spec?

[myfonj]

This is a neat idea. Just two (sad) remarks about status quo from random passers-by:

1. IIUC, Unicode "dictates" only a subset of Emoji (spec, txt) to have both "print" (monochrome) and "picture" (colourful) variants, that should be possible to enforce by using Variation Selector-15 or ..-16 respectively. (This is sad, I wish every single Emoji had mandatory regular monochrome representation alternative.)
2. Actual implementation is currently even worse; it seems that for example Android does not have or does not let you select Text variant for most of those "mandatory" glyphs (test):

OS	Google Chrome	Mozilla Firefox
Android
Windows 10

So the only browser that passes this test is Mozilla Firefox on Windows 10. Google Chrome on Windows 10 let's us set the monochrome (or colourful) font only when forced with explicit font-family (Sogoe UI Symbol / Segoe UI Emoji respectively), so it basically disregards variation selector altogether the moment when it gets font-family directive that sets some font that claims support of given character, or at least it appears to do something like this (test grid):

Firefox on Windows 10	Chrome on Windows 10

(This particular character – 🐾/🐾︎/🐾️ – is not present in that tested "Emoji Presentation Sequences, v15.1" list. Using as illustration for semi-related reasons (*).)

[myfonj]

There are quite promising statements in recent Microsoft announcement about Segoe UI in Windows 11 regarding monochrome Emoji variant:

https://microsoft.design/articles/bringing-new-emoji-to-windows-11 (tweet)

Additionally, they created 2D and monochrome versions of each emoji.

and

We're referring to this new font as a hybrid because it contains COLRv1, COLRv0, and monochrome glyphs. If an application supports COLRv1, the font displays COLRv1; if not, then the application uses one of the other two versions. A hybrid font is a revolving door of adaptability and different styles. "It's pretty groundbreaking. Nobody in the world is currently shipping a font that does this," said Senior Program Manager Judy Safran-Aasen, [...]

[alisonmaher]

Thanks @myfonj for the update here, adding it to the agenda to see if it is something we should incorporate into the forced colors mode spec

[svgeesus]

To some extent this also depends on whether the emoji font is vector or raster, which depends on the platform. Changing the colors of pixels in a raster image (apart from simple grey-scaling, which is unlikely to look good in all cases) is harder than changing the colors in a palette or selecting an alternate palette.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] Emojis in forced colors mode, and agreed to the following:

• RESOLVED: use monochrome emoji in forced-colors mode if the font-variant-emoji property is set to normal or unicode

The full IRC log of that discussion

<TabAtkins> alisonmaher:
<emeyer> alisonmaher: Today we aren't doing anything special
<emeyer> …Proposal is to call back to monochrome versions of emojis in forced-color mode
<emeyer> …Or else, no change to what happens now
<emilio> I think making font selection depend on forced-colors feels a bit too subtle
<emeyer> astearns: Any opinions?
<emilio> But also I don't think it matters much one way or the other
<emeyer> (silence)
<emeyer> ChrisL: Could you explain the interaction with variation selectors?
<emeyer> alisonmaher: I'm not familiar with that
<TabAtkins> q+
<astearns> ack emilio
<astearns> ack TabAtkins
<emeyer> TabAtkins: I think overall this looks reasonable
<emeyer> …The effect looks right
<emeyer> …Chris's point about grayscaling emoji is well taken but I don't think there's a good solution here
<emeyer> s/emoji/raster emoji/
<emilio> q+
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask if this should depend on font-variant-emoji
<emeyer> …We should maybe add a note about that case if we know what we want to say
<emeyer> fantasai: We have a font-variant-emoji proeprty, and I'm wondering if this should depend on that
<fantasai> normal | text | emoji | unicode
<emilio> q-
<emeyer> fantasai: Where normal means the user gets to choose and platform conventions are followed
<emeyer> …text means 15, emoji is 16, unicode is follow unicode's table
<emeyer> astearns: Are you suggesting we change to normal?
<emeyer> fantasai: Maybe to normal and unicode?
<emeyer> alisonmaher: That sounds reasonable to me
<dbaron> s/15/variation selector 15/
<emeyer> astearns: Does that answer your question, Chris?
<emeyer> ChrisL: Not sure, but it seems to say this would work with variation selectors unless you did a certain thing, and then it owuldn
<astearns> ack emilio
<emeyer> s/owuldn/wouldn't/
<emeyer> fantasai: The unicode value is the one that honors the variation selectors
<emeyer> …text ignores whatever's happening according to unicode rules and use text, and emoji also ignore the rules and use the color emoji
<emeyer> astearns: If I'm following, then are we coming to using monochrome emoji in forced-colors mode if the font-variant-emoji property is set to normal or unicode
<emeyer> fantasai: Alternative proposal is to use it for normal and unicode unless variation selector 16 is present, in which case allow that character to override and present in color
<emeyer> alisonmaher: Don't have a strong opinion here
<emeyer> fantasai: The advantage of the latter proposal is an author could pick out a specific character they want but I doubt people are doing that, so I lean tothe first option
<emeyer> s/tothe/to the/
<emeyer> ChrisL: Currently FF is the onlny browser to pass the relevent tests
<emeyer> astearns: But not Safari, which doesn't have forced-color modes, yes?
<ChrisL> I meant in general, the font-variant-emoji property
<emeyer> RESOLVED: use monochrome emoji in forced-colors mode if the font-variant-emoji property is set to normal or unicode
<ChrisL> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-emoji-valid.html?label=experimental&label=master&aligned
<ChrisL> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-emoji-computed.html?label=experimental&label=master&aligned

[yisibl]

To summarize, CSS authors can add styles like this.

:root, input, button, textarea, select {
  font-variant-emoji: emoji;
}
@media (forced-colors: active) {
  :root, input, button, textarea, select {
    font-variant-emoji: normal;
  }
}

[alisonmaher]

Authors could do this, but the resolution was to have browsers fall back to monochrome emojis by default in this mode - this behavior, though, has not yet been implemented