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. 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... 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? [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. -- 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/1688877095666.1486611675.3861536323%40chromium.org.
