Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#38113 closed enhancement (fixed)

Update Twemoji for Emoji 4.0

Reported by: pento's profile pento Owned by: pento's profile 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
8 years ago

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

#2 follow-up: @superpoincare
8 years 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 8 years ago by superpoincare (previous) (diff)

#3 in reply to: ↑ 2 @peterwilsoncc
8 years 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
8 years 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
8 years 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
8 years ago

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

Re-opening for 4.6.2.

#7 @pento
8 years 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
8 years 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
8 years ago

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

#10 @superpoincare
8 years 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 8 years ago by superpoincare (previous) (diff)

#11 @superpoincare
8 years 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
8 years ago

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

#13 @superpoincare
8 years 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
8 years 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
8 years 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 8 years ago by superpoincare (previous) (diff)

#16 @helen
8 years 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.