- From: John Daggett <jdaggett@mozilla.com>
- Date: Thu, 21 Aug 2014 00:37:52 -0700 (PDT)
- To: www-style list <www-style@w3.org>
- Cc: public-webfonts-wg <public-webfonts-wg@w3.org>
As emoji fonts gain popularity across platforms, authors are starting to run into problems where they end up getting a color emoji glyph for a symbol they desire to be monochrome (for an example bug report, see [1]). I'm thinking it might make sense to have a CSS property to allow authors to explicitly control this: font-variant-color: auto | color | monochrome initial value: auto The 'auto' value means the user agent determines which to use. In some contexts, it might make sense to prefer monochrome glyphs (e.g. a reader app) while in other contexts color glyphs might always be preferred (e.g. a messaging app). Or a user agent might decide this based on codepoint, using color glyphs for the emoji range (U+1F300–1F5FF) while preferring monochrome glyphs for standard Unicode symbol ranges. The 'color' value means use color glyphs if available, the monochrome glyph otherwise. The 'monochrome' value means avoid using the color glyph and use the monochrome glyph. Like other font-variant property values, this would only affect glyph selection. If alternate glyphs are not available, using this property would not affect how text is rendered. User agents must not try and simulate fallback glyphs for fonts lacking color glyphs. For authors, this property would assure that they didn't need to worry about which font is used on which platform. By using 'font-variant-color: monochrome' they would guarantee that they wouldn't see color glyphs. I should note here that all the color font formats in use currently (Apple/Google/Microsoft/SVG) all add additional tables to a TrueType font to contain the color glyph data. So there are typically monochrome glyphs for all characters but not necessarily color glyphs. Thoughts? Regards, John Daggett Mozilla Japan [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1054780
Received on Thursday, 21 August 2014 07:38:24 UTC