Sorry for my delay. Strictly speaking, the emoji fallback issue is not part of this proposal. But that sounds like a related issue, so I will take a look at it as a drive-by.
-- ChangSeok > On Jul 16, 2023, at 7:24 AM, Ollie W <[email protected]> wrote: > > Could this issue be fixed as part of this work? > https://stackoverflow.com/questions/70993962/emoji-variation-selector-doesnt-work-for-user-specified-font > It is inconsistent with other browsers. When you explicitly state that you > want an emoji, or text, the order of your font stack shouldn't effect that. > > On Tuesday, July 11, 2023 at 7:56:36 AM UTC+1 ChangSeok Oh wrote: > Thanks for clarifying the question. > > > On 7/8/23 21:40, Sangwhan Moon wrote: >> >> On 2023年07月08日 07時03分10秒 (+09:00), ChangSeok Oh wrote: >> >> > How so? >> >> Sorry, what is your question? >> >> If you were asking why the TAG review status was Not applicable, I have no >> idea. That is the default text for unanswered slots at chromestatus.com. >> Gecko implemented this feature first, so they might try the TAG review. I >> cannot find the pointer, unfortunately. >> >> The question was why it is not applicable (also related to the lack of an >> explainer, been observing and noticing this particular pattern around CSS >> features - so trying to understand the *why*) - what particular >> user/developer need are you trying to solve here, and does that warrant >> revisiting whether or not this is the right approach to tackle the problem. > I think font-variant-emoji can help reduce the developer's chore in > controlling the representation of emoji shapes and unwanted copy-paste > results incurred by prefixing variation selectors [1, 2]. I would not say > this API is the right direction or the only solution to solve that problem, > but I could find developers' voices and expectations related to this API from > the web [1, 2, 3, 4, 5]. > > [1] > https://stackoverflow.com/questions/32915485/how-to-prevent-unicode-characters-from-rendering-as-emoji-in-html-from-javascrip/76583273#76583273 > [2] > https://stackoverflow.com/questions/64172221/change-the-presentation-of-emojis-to-be-plain-text-like-with-css > [3] > https://nolanlawson.com/2022/04/08/the-struggle-of-using-native-emoji-on-the-web/ > [4] https://twitter.com/tomayac/status/1643703278713151488 > [5] https://twitter.com/hypeddev/status/1644727445507956737 > > >> Gecko's implementation seems to be behind a flag [1], so the wild usage I'd >> imagine is very low. I think we'd want to understand why the Gecko >> implementation never got properly rolled out as well... > I have no idea about their release plan. But I found that feature was > implemented and added to the main trunk relatively recently [6]. Perhaps, > Gecko maintainers thought the API was not ready to go in public? > > [6] https://groups.google.com/a/mozilla.org/g/dev-platform/c/F9nrJbPX60A > > >> >> Re: Dominik's comment - I'd imagine one could consider it orthogonal, but >> wouldn't this feature be moot if the missing glyphs remains an unsolved >> problem? > We can discuss the missing glyph cases. My point was solving the problem by > bundling new emoji fonts in chromium binary is beyond my intention and the > scope of prototyping font-variant-emoji. > Suppose your question concerns the fallback strategy where a necessary emoji > is missing. In that case, I will refer to the current fallback behavior of > displaying emoji with the variation selector and Gecko. > If you were asking if having font-variant-emoji would still be meaningful > even where the browser lacks full emoji support. Yes, it is because the users > can actively resolve the missing glyph issues by adding their emoji font to > the font-family and still want to control the emoji shape via CSS. > > Hopefully, my answer cleared up your concerns. > > >> >> [1] >> https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-emoji#browser_compatibility >> >> >> On Friday, July 7, 2023 at 5:42:54 AM UTC-7 Sangwhan Moon wrote: >> >> >> On 2023年07月06日 19時02分40秒 (+09:00), ChangSeok Oh 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 >> How so? >> >> >> >> 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. > > -- > ChangSeok -- 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/D6E2B1AF-69CB-4A55-B46F-8CC3C367AA96%40gmail.com.
