Intent to Prototype: CSS font-variant-emoji

[ChangSeok Oh]

Contact emails
changs...@bytedance.com, shiva...@gmail.com

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.

[Dominik Röttsches]

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

--
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 blink-dev+...@chromium.org.
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.

[Nolan Lawson]

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

[Sangwhan Moon]

On 2023年07月06日 19時02分40秒 (+09:00), ChangSeok Oh wrote:

Contact emails
changs...@bytedance.com, shiva...@gmail.com

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?

--

[ChangSeok Oh]

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

[ChangSeok Oh]

> 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.

[Sangwhan Moon]

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

[Sangwhan Moon]

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.

I'm curious why it was marked not applicable, as this 

[Yoav Weiss]

On Sun, Jul 9, 2023 at 12:52 PM Sangwhan Moon <s...@chromium.org> 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.

I'm curious why it was marked not applicable, as this 

+Jason Robbins - filed https://github.com/GoogleChrome/chromium-dashboard/issues/3144

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1688872802585.1852831217.3574537673%40chromium.org.

[ChangSeok Oh]

Sorry, what is your question?

If you were asking why 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. Unfortunately, I cannot find the pointer.

--
ChangSeok

> On Jul 7, 2023, at 5:42 AM, Sangwhan Moon <s...@chromium.org> wrote:
>
> How so?

[ChangSeok Oh]

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

[ChangSeok Oh]

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.

-- 
ChangSeok

[Ollie W]

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. 

[ChangSeok Oh]

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