WordPress.org

Make WordPress Core

#38113 closed enhancement (fixed)

Update Twemoji for Emoji 4.0

Reported by: pento Owned by: pento
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Emoji Keywords: fixed-major
Focuses: Cc:

Description

Twemoji just added support for the Emoji 4.0 spec, which is due to be finalised in November.

Here's a more readable list of the changes: http://blog.emojipedia.org/twemoji-2-2-emoji-changelog/

Changes we need to make to add support:

  • Upload the new images to w.org (there are altered images, so it'll need a new directory).
  • Change the URL in core to match (_print_emoji_detection_script(), wp_staticize_emoji())
  • Update twemoji.js.
  • Add a new emoji4 test to the loader.

As we've done in the past, emoji updates can be backported to the latest point release, too.

Change History (16)

#1 @pento
13 months ago

  • Owner set to pento
  • Status changed from new to assigned

#2 follow-up: @superpoincare
13 months ago

Apologies if I am wrong, can't the feature detection now simply test rainbow emoji and decide whether to download wp-emoji-release.min.js?

The remaining feature detection can be done in the this js file itself.

This way, some performance loss in createElement("canvas") can be avoided. Mac Sierra browsers and future browsers will just see one detection test.

EDIT: Ignore the comment. Unicode 9.0 also seems important. So Sierra doesn't have it yet.

Last edited 13 months ago by superpoincare (previous) (diff)

#3 in reply to: ↑ 2 @peterwilsoncc
13 months ago

Replying to superpoincare: for this ticket the tests can be added as they have been in the past and any improved practice worked out in #37817. There's some really helpful info on the other ticket.

#4 @pento
13 months ago

The new static assets have been deployed on s.w.org in the 2.2.1 directory.

https://s.w.org/images/core/emoji/2.2.1/72x72/1f469-1f3fd-200d-1f4bb.png

#5 @pento
13 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 38717:

Emoji: Add support for the upcoming Emoji 4 release.

Emoji 4 adds 32 new professions, (with variations for gender and skin tone), and updates 33 existing character for male and female variations.

Fixes #38113 for trunk.

#6 @pento
13 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening for 4.6.2.

#7 @pento
13 months ago

In 38724:

Emoji: Update some failing unit tests.

The changes in [38717] weren't reflected in the associated unit tests.

See #38113.

#8 @superpoincare
13 months ago

Hi @pento

Great. Also the emoji files at present are not gzipped and a it's a nice small performance gain to have them gzipped.

The UN flag svg for example is about 45KB unzipped and can be gzipped to 12KB which is a large reduction. Both MaxCDN and cdnjs where they are also hosted send them gzipped and IMO s.w.org should too.

#9 @pento
13 months ago

Thanks for the reminder, @superpoincare! I've asked the Systems team to investigate options.

#10 @superpoincare
13 months ago

Hi again @pento,

There's one thing I noticed.

You are testing for the rainbow flag support and Mac Sierra has support for it. But I see Wordpress site https://wordpress.org/news/2016/08/wordpress-4-6-rc2/ which has the rainbow flag overrriding the native emoji with svg fetched from s.w.org. I tested it in Chrome 55 Dev on Mac Sierra on Browserstack.

Here's what I get by playing with development tools. (Emoji after "yet" added by me, the one below in original)

http://i.imgur.com/5F00Zs6.png

I am assuming the code tries to use native emoji as much as possible, so the expected behaviour is to not fetch the svg in this case. And if that's not the case, you'll just need one test for the whole code (woman technologist: medium skin tone).

Last edited 13 months ago by superpoincare (previous) (diff)

#11 @superpoincare
13 months ago

Additional comment with correction to last part of my previous comment:

The Shrug emoji is both in unicode 9 and emoji 4 with the latter having various variations. So won't one emoji: Woman Shrugging, Type-4 be enough for feature detection?

https://s.w.org/images/core/emoji/2.2.1/72x72/1f937-1f3fd-200d-2640-fe0f.png

It will be odd for a browser to have support for this emoji (which is a part of Emoji 4.0) and no unicode 9 support.

So this alone can be used to feature detect right?

#12 @pento
13 months ago

Hey @superpoincare, we're looking at improving the tests in #37817.

#13 @superpoincare
11 months ago

Twemoji has updated to 2.2.2, so Wordpress might need to update if necessary. The update is deprecating support for skin tones for multiperson emoji.

#14 @pento
11 months ago

In 39319:

Emoji: Update Twemoji fallback to version 2.2.2.

This removes support for the skin tone modifier on emoji involving two or more people. This functionality is opposed by Apple and Google, so there is unlikely to be an input mechanism for such emoji, they oppose it on the grounds that they "...do not think a mechanism should be supported that only permits depiction of multi-person groups (or elements) in which each person has the same skin tone."

See their official notification for further details: http://www.unicode.org/L2/L2016/16332-remove-multi-emb.pdf

This change does not require a CDN update, as no emoji were altered or added, only removed.

See #38113.

#15 @superpoincare
11 months ago

Replying to pento:

Thanks for the reminder, @superpoincare! I've asked the Systems team to investigate options.

I observed that Wordpress is now serving emoji via http2 and also has gzip compression. This is great!

Last edited 11 months ago by superpoincare (previous) (diff)

#16 @helen
11 months ago

  • Milestone changed from 4.7.1 to 4.7
  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.