There is a proposal to use Unicode variation selectors to disambiguate
between color and monochrome renderings of emoji / symbols.
http://www.unicode.org/reports/tr51/tr51-1d.html
I'm not necessarily advocating that approach over specifying it at a font
level, just pointing out that there is a proposal on the table to handle
this use case. I think variation selectors are considered pretty arcane for
the vast majority of web developers.
Raph
On Thu, Aug 21, 2014 at 7:31 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:
> On Thu, Aug 21, 2014 at 12:57 AM, John Daggett <jdaggett@mozilla.com>
> wrote:
> >
> > Currently CSS defines a set of five generic fonts [1]:
> >
> > serif, sans-serif, monospace, cursive, fantasy
> >
> > I'd like to propose expanding this to include a generic font for
> > emoji characters:
> >
> > emoji
> >
> > The 'emoji' value would map to whatever emoji font is available on a
> > given platform (e.g. Apple Color Emoji, Segoe UI Emoji, Noto Color
> > Emoji).
> >
> > Part of the motivation here is that when Unicode defined a mapping
> > of emoji characters into Unicode, it explicitly unified some of
> > these with existing symbol codepoints. If an author relies on system
> > font fallback to choose a font there's no guarantee an emoji font
> > will be prioritized over a symbol font, since it's difficult for a
> > user agent to distinguish between symbol vs. emoji usage. Specifying
> > the 'emoji' value in a fontlist would prioritize the use of color
> > glyphs for all codepoints covered by the emoji font.
>
> This seems reasonable to me, given the overlap in symbols and emoji.
>
> ~TJ
>
>