- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Mar 2017 02:05:58 +0000
- To: public-css-archive@w3.org
One person's bug is another person's feature! Sorry for sounding so antagonistic there. > You definitely can do this by putting your own fonts inside font-family. I'm not sure that's currently true everywhere. It didn't used to be true on Chrome on Windows, although I tested & it is true now on Win 10, anyway. Probably related to using the system font as their Emoji font, instead of subbing their own bitmaps. But while testing that, I also confirmed that all three major browsers on Windows 10 currently will use *any* emoji font you specify in the font stack, even if it's monochrome. So my tentative definition of `auto` fails on that point, too. Which is one more factor to convince me that `auto` can't be explicitly defined. It will be "let the browser do as it wishes," whatever that is. Hopefully somewhat consistent with Unicode, and somewhat consistent with platform conventions. I'm more concerned about having clear definitions for the other options, so that authors can reliably control the behavior if it is important. An explicit color/emoji option, to search the stack or system fallback fonts for a color glyph before falling back to monochrome, and an explicit monochrome/text option, to do the same search looking for monochrome. (And possibly, a fill/stroke option, to look for a monochrome glyph and then paint it with fill & stroke instead of solid color. But that could be added by the proposed Paint spec, if it is determined to be useful.) -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/352#issuecomment-285232256 using your GitHub account
Received on Thursday, 9 March 2017 02:06:04 UTC