Re: Unicode request for CSS property to control emoji style [I18N-ACTION-500]

This discussion seems to be focused on the situation where the preferred
font has both multi-color and monochrome versions for a character, deciding
which one should be selected.

This seems a natural choice for a font-variant-* property.  As Cameron
said, this switch isn't even specific to emoji characters, although having
an `multicolor-if-emoji` option that defers to the Unicode emoji setting
for each character is useful.

The more prevalent situation, however, is whether the text layout engine
should replace the glyph from the normal font stack with a multi-color
glyph from the system emoji font (as many browser/OS combinations currently
do).

This second issue is more complex, as it somewhat up-ends the normal glyph
selection rules.  Essentially, the behavior of many user agents (e.g., most
browsers on mobile) is to treat the generic emoji font as if it is the
first choice in every font stack.  In contrast, other UAs (e.g., Firefox on
Windows) treat the emoji glyphs as part of a generic fallback font that is
only displayed if the author-specified font stack does not have a glyph for
the character.

This is not a font-variant-* option, as it isn't a property of a particular
font, but of how the font stack is used to resolve a given character.

Some practical cases to consider:

1) The author provided explicit font settings for a design which should be
rendered with specified color (or SVG paint) styles for all the characters,
even usual emoji characters.

I don't think this is currently possible on systems that usually substitute
their own emoji glyphs.

2) The author wants characters to be displayed using the system emoji font
if available, but has also provided a web font as a fallback to ensure that
glyphs can be rendered even if not supported in the system font.

Currently, the only way to do this in Firefox is to add Firefox's default
emoji font to the top of the font stack.  If other browsers adopt the same
behavior, more font names would be required.  It will become easier when
the generic `emoji` font keyword is well-supported, but it's still kind of
weird to put a generic font keyword at the top of the font stack instead of
as the fallback.

Having the emoji font as the first font in the stack also has side effects,
preventing font-variant settings from being applied to the text rendered in
the primary font (which is now listed as a fallback in the font-family
property).  There are probably some workarounds that use @font-face's
Unicode range option to synthesize a font family consisting of the correct
glyphs for each character, but that's getting painfully complex.


In other words, I think a new property would be required that specifically
instructs the user agent to substitute (or not) emoji glyphs, regardless of
font-family settings.


~ABR