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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbd14799-408d-4405-8db3-82cdaa7678b6n%40chromium.org?utm_medium=email&utm_source=footer>.
--
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/eaf73313-50cb-bbff-184c-d8fce7f0af27%40gmail.com.
