Hi all, I'm piping up because I'm an emoji picker author, and I wrote a long post on this subject: https://nolanlawson.com/2022/04/08/the-struggle-of-using-native-emoji-on-the-web/
As far as I can tell, font-variant-emoji solves one of the problems described in my post, which is the need for the variation selector for certain characters. Dominik Röttsches's comment is correct, though – font-variant-emoji doesn't solve the whole problem. If Chrome were to ship with an emoji font (as Firefox does), then that would solve the problem of missing characters on Windows, captured in this bug (closed as WontFix): https://bugs.chromium.org/p/chromium/issues/detail?id=1209677 (Windows has two problems: no country flags, and Windows 10 not getting newer emoji.) Due to that bug (and other issues, such as outdated iOS Safari versions with old emoji), I suspect that most web app authors will continue to ship large third-party emoji fonts/spritesheets rather than use native emoji. However, I believe font-variant-emoji is a step in the right direction. Cheers, Nolan On Thursday, July 6, 2023 at 5:47:24 AM UTC-7 Dominik Röttsches wrote: > Hi ChangSeok, > > Could you explain a bit further what the intended outcome of this > prototyping will be? From my experience, incorrect presentation style > (text/emoji) for emoji is more often a problem of font availability and > glyph coverage than it is a problem of controlling the representation. I am > not convinced the font-variant-emoji property solves this problem on its > own. It's true that the property is an alternative for variation selectors > (which are not vague). But once the presentation style is specified, > finding a correct font, in particular for text presentation of symbols, is > often the more fundamental problem. The latter would require solving to > always succeed in selecting alternative presentation forms. One solution > approach is to ship Noto Color Emoji and Noto Emoji, or somehow make them > available to Chrome on each platform - but that has not been done yet, as > we likely can't grow the Chrome binary by that much. > > Can you describe at which level in the stack do you plan to operate here, > and which problem you're solving? > > Dominik > > > On Thu, Jul 6, 2023 at 1:02 PM ChangSeok Oh <[email protected]> wrote: > >> *Contact emails* >> [email protected], [email protected] >> >> *Explainer* >> None >> >> *Specification* >> https://www.w3.org/TR/css-fonts-4/#font-variant-emoji-prop >> >> *Summary* >> The CSS property font-variant-emoji determines the default style used to >> display emojis. In the past, this was achieved by adding a Variation >> Selector, specifically U+FE0E for text and U+FE0F for emojis, to the >> emoji's code point. However, font-variant-emoji allows web developers to >> select the emoji representation via keywords: normal, text, emoji, and >> unicode. This property only affects emojis that are part of a Unicode emoji >> presentation sequence [1]. >> >> [1] http://www.unicode.org/emoji/charts/emoji-variants.html >> >> *Blink component* >> Blink>Fonts>Emoji >> >> *Motivation* >> Font-variant-emoji helps web developers control representation types of >> emoji (e.g., text, emoji, Unicode, etc.) via CSS. That is more >> straightforward and explainable than embedding vague code sequences into >> the content. >> >> *Initial public proposal* >> None >> >> *TAG review* >> None >> >> *TAG review status* >> Not applicable >> >> *Risks* >> >> *Interoperability and Compatibility* >> >> *Gecko*: Positive ( >> https://bugzilla.mozilla.org/show_bug.cgi?id=1461589) >> >> *WebKit*: In development ( >> https://bugs.webkit.org/show_bug.cgi?id=246911) >> >> Web developers: No signals >> >> Other signals: >> >> *WebView application risks* >> Does this intent deprecate or change behavior of existing APIs, such >> that it has potentially high risk for Android WebView-based applications? >> None >> >> >> *Debuggability* >> >> *Is this feature fully tested by web-platform-tests?* >> Yes >> >> *Flag name on chrome://flags* >> To be decided >> >> *Finch feature name* >> None >> >> *Non-finch justification* >> None >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://bugs.chromium.org/p/chromium/issues/detail?id=1379029 >> >> *Estimated milestones* >> No milestones specified >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/6566092561973248 >> >> *Links to previous Intent discussions* >> None >> >> This intent message was generated by Chrome Platform Status. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbd14799-408d-4405-8db3-82cdaa7678b6n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbd14799-408d-4405-8db3-82cdaa7678b6n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/964f8011-318c-4d49-9e5b-0d719fe15f3en%40chromium.org.
