Inconsistent Emoji when sans-serif is Noto Sans CJK/Source Han Sans

[Small-Ku]

Bug report:

• Operating system and version: All system in concept, especially Linux distros that with Chinese support
• Browser and version: All browsers that can set font for sans-serif
• Reduced test case: https://jsbin.com/gobared/

Steps:

1. Set browser default sans-serif to Noto Sans CJK/Source Han Sans, which is commonly used as Chinese/Japanese/Korean font in Linux distros.
2. Open a site with Emoji that built with Bootstrap

Screenshot:

Suggested fix: Put Emoji fonts in front of text fonts like

$font-family-sans-serif:
  // Safari for OS X and iOS (San Francisco)
  -apple-system,
  // Chrome < 56 for OS X (San Francisco)
  BlinkMacSystemFont,
  // Emoji fonts
  "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji",
  // Windows
  "Segoe UI",
  // Android
  "Roboto",
  // Basic web fallback
  "Helvetica Neue", Arial, "Noto Sans"
  , sans-serif !default;

[XhmikosR]

@ffoodd @patrickhlauke can we close this since #31960 has landed?

[patrickhlauke]

@XhmikosR i think this is slightly different aspect. #31960 warns about unicode chars being replaced by emoji that then can't be styled colour-wise, while this issue highlights that in some cases the emoji fonts are not kicking in, if i understand it correctly ... i.e. the opposite issue of what #31960 describes.

would reshuffling the order in which the fonts are called have any other adverse effects? if not, i'd say go for the suggested fix here (though to clarify, i assume this is just about moving the emoji fonts and not duplicating it like in the above code block?)

[mdo]

Hesitant to merge this without a thorough test. Would someone want to jump in and explore?

[ffoodd]

If I understand what's going on, those kick in as sans-serif keyword value. So that makes me wonder: what if we simply move sans-serif keyword after the emoji fonts? Would it work?

[patrickhlauke]

yes I believe that's, roughly, the request here in the thread starter. I think the only situation where this would have an adverse effect is where/if we/an author rely on a unicode char to kick in rather than an emoji char - but I believe that we've now consistenly moved to using SVGs rather than unicodes for things like "x" close controls, so can't think of situations where our components would be affected in any way.

[ffoodd]

Agreed, and even in that case it'd only need some font-family love for this specific situation. I'd say: let's try simply moving sans-serif after emoji fonts.