Bug 246911 – [css-fonts] Implement `font-variant-emoji` CSS property

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Tim Nguyen (:ntim)]

font-variant-emoji: normal | text | emoji | unicode

https://drafts.csswg.org/css-fonts-4/#font-variant-emoji-prop

[Radar WebKit Bug Importer]

<rdar://problem/101722745>

[ChangSeok Oh]

Is anyone working on this? I am curious if the WebKit community wants to support this.

[Tim Nguyen (:ntim)]

(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!

[Myles C. Maxfield]

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

[ChangSeok Oh]

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

[Myles C. Maxfield]

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.

[Myles C. Maxfield]

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.

[Myles C. Maxfield]

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.

[ChangSeok Oh]

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

[Tim Nguyen (:ntim)]

Pull request: https://github.com/WebKit/WebKit/pull/17281

[Tim Nguyen (:ntim)]

Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/41730

[EWS]

Committed 267540@main (19378f7d7d7d): <https://commits.webkit.org/267540@main>

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