[css-fonts][css-text] Variation Selection of Colorful (Emoji) or Monochrome Glyphs

[Crissov]

In late March, on www-style, Addison Philips posted a request on behalf of W3C’s I18N WG to be able to control the style of emoji characters via CSS. There were links to the relevant I18N minutes and Unicode minutes as well as the reference document UTR51.

default : style characters to use each character's default display
text : style characters to use their text display
emoji : style characters to use their emoji display

The issue had been brought up in 2014 already, but I cannot find a WG conclusion on it. It has been suggested to be handled by font-variant-color (John Dagget), font-variant-emoji (Xidorn Quan @upsuper), “something more generic” or @font-palette (Cameron McCormack @heycam) or “a new property” (Amelia Bellamy Royds @AmeliaBR).

I agree with some of the concerns that this is not an issue appropriate to be handled by font-variant-*, not just because there’s no corresponding Open Type feature. I was about to propose the selection being part of text-transform, but I then realized that this would only be reasonable to override or synthesize variation selectors (U+FE0E = VS-15 ‘text’, U+FE0F = VS-16 ‘emoji’). UTR51 wants VSs to take precedence over normal styling, though. I suggest we add both capabilities!

font-color: 'auto' | 'monochrome' | 'colorful'  | <color>+

text-transform: <text-transform-case> || <text-transform-width> || <text-transform-variation>
text-transform-case: 'none' | 'capitalize' | 'uppercase' | 'lowercase'
text-transform-width: 'none' | 'full-width'
text-transform-variation: 'none' | 'text' | 'emoji'

Bikeshedding welcome.

[AmeliaBR]

To clarify the interaction of these properties, can you confirm whether these are the intended outcome of the following combinations?

• Colorful text:

  font-color: colorful;
  text-transform-variation: text;

  Use the multi-color default palette defined in the font, if there is one (or fallback to currentColor otherwise).

• Custom colorful text:

  font-color: tomato royalBlue indigo;
  text-transform-variation: text;

  Use the specified colors as a three-color palette for the font, if it supports it (or fallback to currentColor otherwise).

• Default OS emoji + monochrome:

  font-color: monochrome;
  text-transform-variation: emoji;

  Substitute in standard OS full-color emoji if they are available; render all other glyphs with currentColor, regardless of the color palettes available in the font.

• OS emoji + full-color font:

  font-color: auto;
  text-transform-variation: emoji;

  Substitute in standard OS full-color emoji if they are available; render other glyphs with the font's default full-color palette if available, or with currentColor otherwise.

If I've got that all correct, my remaining questions are:

• Is there a meaningful difference between auto and colorful? I'm assuming both mean "use the default font palette if available". Would they behave differently if the font doesn't have a color palette, e.g., with fallback to currentColor?
• How do the multi-color syntax and the keywords interact with the use of CSS variables to set font palette colors individually?

[svgeesus]

@font-palette (Cameron McCormack @heycam)
I prefer @font-palette, as described in CSS4 Fonts:
https://drafts.csswg.org/css-fonts-4/#font-palette-control

Both of the vector-format chromatic font options in OpenType v.3 use palettes, via the CPAL table, so a way to override these from CSS is needed. Putting this in an at-rule allows the same font to be used with different palettes at the same time.

[Crissov]

Oh, I only checked css-fonts-3 briefly and thus missed that font-palette and @palette-entries are already drafted for level 4, also didn’t see the original full proposal. Thanks for the heads-up, @svgeesus. I think I agree with the chosen solution for font-defined palettes, but I believe there should be a simple way to get monochrome glyphs using only currentcolor or shades thereof, which seems more appropriate for the vector variants, COLR and SVG, than for bitmap CBDT. My font-color: <color>+ was intended to either make a user-defined palette or populate --color1 etc. easily and @AmeliaBR is right, I hadn’t thought through the exact meaning of auto.

Nevertheless, my point regarding text-transform[-variant] stands and I think the expected results are as shown in the table below.

	U+2661	U+2665	U+2764	U+1F499	U+1F5A4
Name	White Heart Suit	Black Heart Suit	Heavy Black Heart	Blue Heart	Black Heart (UC9)
default, none	♡	♥	❤	💙	🖤
VS15 or text	♡︎	♥︎	❤︎	💙︎	🖤︎
VS16 or emoji	♡️	♥️	❤️	💙️	🖤️
VS15 and emoji	♡	♥️	❤️	💙️	🖤️
VS16 and text	♡︎	♥︎	❤︎	💙︎	🖤︎
emoji and monochrome	♡	🖤️	🖤️	🖤️	🖤️
text and monochrome	♡︎	♥︎	❤︎	🖤︎	🖤︎

[fantasai]

Just a quick comment on the `text-transform` aspect... If we decide to handle this by manipulating variant selectors, then I think this should be handled as a separate `text-variant` property, and not mixed up with what, to an author, is more clearly a text transformation. ~fantasai

[kojiishi]

I'm confused what this thread is talking about. It looks like the first comment was about choosing emoji/text representation, the same functionality as VS15/VS16. But then other people are talking about changing color palette only for Emoji fonts. Which are we talking about?

Either way, this is about font selection and rendering, they should be font-, not in text-.

[Crissov]

This issue is about both features and how to distinguish them, @kojiishi.

text-transform is about using the glyph of a different character than the one encoded or, some may argue, changing the code of the character and thus the glyph. Variation selectors are a different mechanism to choose an alternative glyph, but – much like font-variant and its foundational Open Type features – usually it’s specific to the encoded character and is not shared with or taken from a different character. That’s why I believe this part belongs into css-text. I think I would be okay with a separate text-… property, though.

Controlling the font palette of multi-color fonts belongs in css-fonts, on the other hand, maybe with considerations in css-color. The features interact insofar that requesting a monochrome palette is often almost the same as transforming all emojis to text style, except that not all emojis support VS-15 as shown with the blue heart in the table. The “black” hearts are always colored red when treated as emoji, but with a monochrome palette they should look much like the newly encoded U+1F5A4 (assuming color: black).

[tabatkins]

The two features aren't really connected in any meaningful way, except weakly by metaphor. Emoji switching is changing the entire glyph used to render the codepoint; multicolor fonts just let you specify the color palette directly.

In particular, rendering a multicolor font with monochrome is the default - if you don't invoke the font-palette property, all the palette colors default to currentcolor.

Since the OP was about emoji transformation, let's stick with that topic. You can split off a separate font palette discussion to another issue.

[svgeesus]

In particular, rendering a multicolor font with monochrome is the default - if you don't invoke the font-palette property, all the palette colors default to currentcolor

That isn't what is currently implemented. Does something in the spec say this?

[Crissov]

There is a related question on Stack Overflow. The answers suggest some shadow hacks to get monochrome or outlined emoji glyphs.

[Crissov]

The lack of being able to enforce monochrome glyphs instead of colorful emojis is an important reason for symbol fonts to use PUA code points, which leads to a11y problems, e.g. FortAwesome/Font-Awesome#222.