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 > >Received on Thursday, 21 August 2014 15:59:16 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:43 UTC