- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Mar 2017 03:22:42 +0000
- To: public-css-archive@w3.org
@litherum How would this affect the actual choice of font? I.e., whether to use the font-family stack, or whether to bypass it and grab a system emoji font? One way to retro-actively describe the current behavior, while still allowing authors to specify alternative emoji fonts (full or mono-color) would be: - If `emoji` is specified, or if `auto` is specified and the character is an emoji character, the browser searches the font stack specifically for a full-color character, falling back if necessary to a full-color system font. If no full-color versions of the character are available, fall back to regular font selection. - If `text` is specified, or if `auto` is specified and the character is not an emoji character, use the normal font selection rules: pick the first font in the stack that can render the character. That said, if these are the rules, I think full-color/monochrome might be better keywords than text/emoji. Also: If there _are_ Unicode variation selector characters in the text, should they over-ride the `emoji`/`text` values, or vice versa? (I assume that the `auto` value would be based on Unicode categories and variation selectors.) -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/352#issuecomment-284935383 using your GitHub account
Received on Wednesday, 8 March 2017 03:22:48 UTC