Bug 246911 - [css-fonts] Implement `font-variant-emoji` CSS property
Summary: [css-fonts] Implement `font-variant-emoji` CSS property
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Nguyen (:ntim)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-10-22 23:02 PDT by Tim Nguyen (:ntim)
Modified: 2023-08-31 20:23 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Nguyen (:ntim) 2022-10-22 23:02:11 PDT
font-variant-emoji: normal | text | emoji | unicode

https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-prop
Comment 1 Radar WebKit Bug Importer 2022-10-29 23:03:18 PDT
<rdar://problem/101722745>
Comment 2 ChangSeok Oh 2023-06-28 14:49:40 PDT
Is anyone working on this? I am curious if the WebKit community wants to support this.
Comment 3 Tim Nguyen (:ntim) 2023-06-28 15:17:39 PDT
(In reply to ChangSeok Oh from comment #2)
> Is anyone working on this? I am curious if the WebKit community wants to
> support this.

No-one is actively working on this, please go ahead if you're interested!
Comment 4 Myles C. Maxfield 2023-06-28 15:27:32 PDT
I think there are 2 ways to implement this:

1. Use the same mechanism that text-transform uses to modify the text to stick variation selectors everywhere
2. Don't modify the text, but instead just tell the underlying font/glyph library (Core Text in our case) to use one kind of glyph mapping / rendering rather than another

I think for the Apple ports, we would probably prefer the second implementation (because it's likely to be more performant because it doesn't involve munging around with the string) but unfortunately it will require Core Text SPI and therefore isn't really something that a non-Apple employee could do.

So, I think there are 2 options for you to go about this:
1. Implement the string-munging option for the non-Apple ports, and work with an Apple employee to get the necessary support from Core Text for the Apple ports
2. Implement the string-munging option for all ports, and we consider the approach temporary for the Apple ports, and eventually someone from Apple adds a new implementation specific to Core Text later
Comment 5 ChangSeok Oh 2023-06-28 17:09:08 PDT
(In reply to Myles C. Maxfield from comment #4)
> I think there are 2 ways to implement this:
> 
> 1. Use the same mechanism that text-transform uses to modify the text to
> stick variation selectors everywhere
> 2. Don't modify the text, but instead just tell the underlying font/glyph
> library (Core Text in our case) to use one kind of glyph mapping / rendering
> rather than another
> 
> I think for the Apple ports, we would probably prefer the second
> implementation (because it's likely to be more performant because it doesn't
> involve munging around with the string) but unfortunately it will require
> Core Text SPI and therefore isn't really something that a non-Apple employee
> could do.
> 
> So, I think there are 2 options for you to go about this:
> 1. Implement the string-munging option for the non-Apple ports, and work
> with an Apple employee to get the necessary support from Core Text for the
> Apple ports
> 2. Implement the string-munging option for all ports, and we consider the
> approach temporary for the Apple ports, and eventually someone from Apple
> adds a new implementation specific to Core Text later

Tim and Myles, thanks for the quick replies.
That sounds like a good plan. I also prefer the non-string-munging option. (No one likes the same job twice ;)) Let me take this bug and give it a shot.
Comment 6 Myles C. Maxfield 2023-07-11 02:20:23 PDT
Have you started on this yet? I am actually implementing something very similar as a bugfix and might want to just implement this as a drive-by. But I don't want to step on your toes if you've already started.
Comment 7 Myles C. Maxfield 2023-07-11 02:22:47 PDT
The bugfix I'm working on is that sometimes emoji characters aren't rendered with an emoji font, because our font fallback logic has no concept of whether a character is an emoji character and requires certain fonts or not. The fix will be to teach our font fallback code about whether or not we should be requiring an emoji font. That logic is required for implementing font-variant-emoji.
Comment 8 Myles C. Maxfield 2023-07-12 12:30:34 PDT
Please see https://github.com/WebKit/WebKit/pull/15772. That patch adds:

```
enum class FontVariantEmoji : uint8_t {
    Normal,
    Text,
    Emoji,
    Unicode,
};
```

and hooks up support for it. The remaining piece for the font-variant-emoji property should only be the actual property parsing.
Comment 9 ChangSeok Oh 2023-07-12 14:03:27 PDT
(In reply to Myles C. Maxfield from comment #6)
> Have you started on this yet? I am actually implementing something very
> similar as a bugfix and might want to just implement this as a drive-by. But
> I don't want to step on your toes if you've already started.

Thanks for letting me know. This ticket was in my queue, but I haven't started yet. Please feel free to go ahead.
Comment 10 Tim Nguyen (:ntim) 2023-08-31 01:36:11 PDT
Pull request: https://github.com/WebKit/WebKit/pull/17281
Comment 11 Tim Nguyen (:ntim) 2023-08-31 01:38:10 PDT
Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/41730
Comment 12 EWS 2023-08-31 20:23:39 PDT
Committed 267540@main (19378f7d7d7d): <https://commits.webkit.org/267540@main>

Reviewed commits have been landed. Closing PR #17281 and removing active labels.