Hi Dominik, I see your concern and agree that font-variant-emoji does not help the representation problem caused by missing glyphs of the used font. However, in my view, the coverage issue is orthogonal to this CSS property and beyond the scope of what we can benefit from font-variant-emoji.
My intention to achieve via font-variant-emoji is the inconsistent and unexpected representation issues in the web application layer under the assumption that the necessary emojis are supported. So, I do not aim at bundling emoji fonts into Chromium binary. As Nolan said in his article, font-variant-emoji can address unexpectedly displayed emoji issues [1]. I quote his text related to that figure. the “smiley face” should be rendered as emoji, but the numbers 0-9 and symbols like * and # should not. Of course, web developers can address such representation issues by prefixing variation selectors to emojis, but it causes a copy-paste churn and a CSS hack thereof [2]. I think font-variant-emoji would be helpful here in addressing those problems. I hope my answer was clear about the motivation and goal. Best, [1] https://nolanwlawson.files.wordpress.com/2022/04/screenshot-from-2022-04-03-14-15-35.png [2] https://stackoverflow.com/questions/64172221/change-the-presentation-of-emojis-to-be-plain-text-like-with-css -- ChangSeok On Thursday, July 6, 2023 at 5:47:24 AM UTC-7 [email protected] 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/96f87f47-d1a0-48aa-a9a5-5338430d6ba8n%40chromium.org.
