There is a CSS draft, I think, but the Unicode 'patch' for this is already real and it works 100% reliably in Safari and with varying and limited success in other browsers, which hopefully will climb aboard the clue train eventually. Just append code point FE0F (Emoji) or FE0E (Symbol) to the ambiguous character.
The story is deeper than just 'font' being the deciding factor, though.
The key thing to know is that a lot of emoji, especially many of the 'first' ones, were actually just existing (black & white) symbols that were mapped to new, color pictograms on emoji-supporting devices. This might sound like a nice backwards-compatible path, but it was, is, and will always be a disaster!
The Unicode Corsortium stupidly, naïvely, regrettably dictated that such characters should render as emoji "in the mobile context" but as symbols elsewhere. A half a moment's thought shows the folly of this incredibly dumb proposal. Say I text you an emoji. Great. Mobile context. And then you copy my text and paste it into an email your phone to your mother. Should the email look dramatically different depending on whether she checks her email on her phone or on a desktop? Madness. On what planet does it make sense for a writing system incorporate the viewing device into its decoding algorithm?
The ambiguity is resolved differently, even character-to-character in the same browser on the same device, as my tiny three-character test suite reveals.
Upsettingly to me, this means that a lot of documents written before emoji existed, or even written today on a non-emoji device such as a Windows 7 box, HAVE BEEN RETROACTIVELY AND PERMANENTLY BROKEN by the Unicode Consortium. Because, let's not kid ourselves: The meaning and tone of a document absolutely changes when one symbol is replaced with a conceptually similar but decidedly different cartoony pictogram.
The story is deeper than just 'font' being the deciding factor, though.
The key thing to know is that a lot of emoji, especially many of the 'first' ones, were actually just existing (black & white) symbols that were mapped to new, color pictograms on emoji-supporting devices. This might sound like a nice backwards-compatible path, but it was, is, and will always be a disaster!
The Unicode Corsortium stupidly, naïvely, regrettably dictated that such characters should render as emoji "in the mobile context" but as symbols elsewhere. A half a moment's thought shows the folly of this incredibly dumb proposal. Say I text you an emoji. Great. Mobile context. And then you copy my text and paste it into an email your phone to your mother. Should the email look dramatically different depending on whether she checks her email on her phone or on a desktop? Madness. On what planet does it make sense for a writing system incorporate the viewing device into its decoding algorithm?
The ambiguity is resolved differently, even character-to-character in the same browser on the same device, as my tiny three-character test suite reveals.
Upsettingly to me, this means that a lot of documents written before emoji existed, or even written today on a non-emoji device such as a Windows 7 box, HAVE BEEN RETROACTIVELY AND PERMANENTLY BROKEN by the Unicode Consortium. Because, let's not kid ourselves: The meaning and tone of a document absolutely changes when one symbol is replaced with a conceptually similar but decidedly different cartoony pictogram.
Source: try it for yourself on https://alanhogan.github.io/system-font-stack-experiments/em... or run that page through e.g. browserstack.com/screenshots.