#31242 closed task (blessed) (fixed)
Global Emoji Support
Reported by: | pento | Owned by: | pento |
---|---|---|---|
Milestone: | 4.2 | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | |
Focuses: | javascript | Cc: |
Description
Once #21212 is complete, then WordPress will support storing emoji in the database.
The problem is, some browsers still don't support displaying emoji. We need to work around their lack of useful features.
Here's a plugin to get things rolling:
Attachments (25)
Change History (93)
#2
follow-up:
↓ 3
@
10 years ago
We should also update the language of the setting. Emojis are different than emoticons.
Because emojis won't be properly displayed outside of the website context (e.g. search results, RSS feeds, email clients, etc.), should we have some compatibility shim to translate the data on the fly?
https://dl.dropboxusercontent.com/s/0v81fuykb81q6oi/2015-02-06%20at%208.53%20AM%202x.png?dl=0
#3
in reply to:
↑ 2
@
10 years ago
Replying to danielbachhuber:
Because emojis won't be properly displayed outside of the website context (e.g. search results, RSS feeds, email clients, etc.), should we have some compatibility shim to translate the data on the fly?
We can definitely do something for RSS, and maybe for email. Not sure about search results, though. I don't know of any way to tell Google (or any search engine) to use an image in search results.
This ticket was mentioned in Slack in #core by pento. View the logs.
10 years ago
#6
follow-ups:
↓ 7
↓ 8
@
10 years ago
As per Slack conversation, uploading a screenshot: alt attributes need some love. See in the dev tools, Firefox and Chrome on Windows. Ideally, the alt attributes should be the emoji name, if not possible, better to have an empty alt attribute in lieu of a character that wouldn't be read out by screen readers or read out in a very weird way.
#7
in reply to:
↑ 6
@
10 years ago
Replying to afercia:
Ideally, the alt attributes should be the emoji name, if not possible, better to have an empty alt attribute in lieu of a character that wouldn't be read out by screen readers or read out in a very weird way.
We often drag-select and Copy text&paste.
That time, images will copy as alt-text..
#8
in reply to:
↑ 6
@
10 years ago
Replying to afercia:
As per Slack conversation, uploading a screenshot: alt attributes need some love. See in the dev tools, Firefox and Chrome on Windows. Ideally, the alt attributes should be the emoji name, if not possible, better to have an empty alt attribute in lieu of a character that wouldn't be read out by screen readers or read out in a very weird way.
See https://github.com/pento/x1f4a9/issues/6 . I reported it upstream to Twitter (as the issue is in the code we're taking from them) and they wontfix'd it.
#9
@
10 years ago
Other issues opened/for discussion:
Emoji not rendered in form fields: https://github.com/pento/x1f4a9/issues/7
Emoji not rendered after ajax actions: https://github.com/pento/x1f4a9/issues/8
A couple of issues with emoji being dropped completely:
text widgets: https://github.com/pento/x1f4a9/issues/9
quick edit: https://github.com/pento/x1f4a9/issues/10
Emoji in terms will display blank slug: https://github.com/pento/x1f4a9/issues/11
Cursor position after TinyMCE emoji render: https://github.com/pento/x1f4a9/issues/12
#10
@
10 years ago
- Focuses javascript added
- Keywords has-patch needs-unit-tests added
Well, 31242.diff sure is a thing.
Currently in need of a JS review, and unit tests.
This ticket was mentioned in Slack in #core by pento. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-editor by pento. View the logs.
10 years ago
#13
@
10 years ago
Just noticed something bit weird in IE 8, see screenshot:
See the space below the admin bar. That space disappears as soon as I disable the Emoji plugin. Reproduced in trunk and 4.1 with Twenty Fifteen and just Twitters Emoji plugin active.
@azaozz pointed out that span is the standard MCE bookmark to keep the caret location in IE, I suspect it shouldn't be appended there.
#14
@
10 years ago
- Keywords commit added; needs-unit-tests removed
- Owner set to pento
- Status changed from new to assigned
31242.2.diff fixes up all the smiley unit tests.
I need some sleep, I'll commit this in the morning, along with #31328.
This ticket was mentioned in Slack in #core by drew. View the logs.
10 years ago
#26
follow-up:
↓ 28
@
10 years ago
I was experiencing an Unresponsive script warning for twemoji until the last patches; testing with 31242.7.patch fixed the issue for me.
#27
@
10 years ago
Returning false in the callback for the image src is a bad idea. We'd need to adjust this in twemoji.
#28
in reply to:
↑ 26
@
10 years ago
Replying to adamsilverstein:
I was experiencing an Unresponsive script warning for twemoji until the last patches
For the record, I was seeing the same thing too.
#29
@
10 years ago
This is what's causing the freezing. Twemoji fails to replace with an image, text node is replaced anyway (it found a match), observer detects change, twemoji parses again... infinite loop.
#31
@
10 years ago
I sent a PR: https://github.com/twitter/twemoji/pull/52
This ticket was mentioned in Slack in #core by azaozz. View the logs.
10 years ago
#33
@
10 years ago
Discussed this with @azaozz and we'll patch twemoji in core. All twemoji tests pass. See PR.
#40
@
10 years ago
Update twemoji to 1.3.1, but still exclude select
. Actually, about that: http://www.w3.org/TR/html-markup/option.html.
option
can only contain a text node.
This is actually a weird territory. Emoji work in Chrome in select
tags because it is native UI, even though Chrome does not support emoji. :)
#41
@
10 years ago
Another TinyMCE bug: linking some text with an emoji is not possible. The emoji just disappears.
#42
@
10 years ago
[31733] broke Tests_Post::test_utf8mb3_post_saves_with_emoji()
for some setups. Here's my local environment:
$ mysql --version mysql Ver 15.1 Distrib 10.0.17-MariaDB, for Linux (x86_64) using readline 5.1
At least in this specific case - where mariadb versioning differs from mysql - the problem traces in part to https://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php?marks=2804#L2780. $wpdb->has_cap( 'utf8mb4' )
is failing (even though my DB does in fact support utf8mb4), and this causes the test not to be skipped as it should (for reasons I have not dug into, but pento probably knows off the top of his head). I'm not sure why [31733] in particular broke this - I think it's the 'utf8' charset check in wp_insert_post()
?
In any case, it's happening on Travis as well: https://travis-ci.org/aaronjorbin/develop.wordpress/jobs/54178126
This ticket was mentioned in Slack in #meta by sergeybiryukov. View the logs.
10 years ago
#45
@
10 years ago
31242.16.patch adds display: inline
to Emoji styles, to avoid them being displayed as a block element (see the screenshot from the recent WordPress Core Weekly post).
#50
@
10 years ago
In 31242.19.patch:
- Move the TinyMCE plugin css to wp-content.css.
- Clean up both the plugin and wp-emoji.js, abstract and restructure a bit.
#53
@
10 years ago
We probably should change the class for the replacement images to wp-emoji
. It is more compatible and future-proof. Any reasons not to?
#54
@
10 years ago
No reason, that was on my to-do list for next week - feel free to take care of it while you're powering through emoji, though. :-)
#56
@
10 years ago
Having some second thoughts about changing the replacement images class name. Not sure how many places use Twemoji but it seems the .emoji
class name may become the "de-facto standard" for these images.
One user case for keeping that unchanged is when pasting in the editor. If there are image tags with .emoji
, we can easily find them and convert them (add the other attributes). Of course we can check for .wp-emoji
too, but using .emoji
will probably help make it into something like a de-facto standard.
#61
follow-up:
↓ 63
@
10 years ago
- Keywords commit removed
@pento: Can we come up with more descriptive names for feed_emoji()
and mail_emoji()
? I don't feel like they really fit with core style in that it's not immediately obvious what purpose they serve. Perhspa something like convert_feed_emoji()
and convert_mail_emoji()
?
#63
in reply to:
↑ 61
;
follow-up:
↓ 64
@
10 years ago
Replying to DrewAPicture:
@pento: Can we come up with more descriptive names for
feed_emoji()
andmail_emoji()
? I don't feel like they really fit with core style in that it's not immediately obvious what purpose they serve. Perhspa something likeconvert_feed_emoji()
andconvert_mail_emoji()
?
For you, @DrewAPicture, we can absolutely do that.
If we want to chat about purpose before deciding on a name, it's worth considering that they're really just single-purpose filters (to be thin wrappers that filter content through wp_staticize_emoji()
), so maybe they're better as _
-prefixed @ignore
-d functions?
Perhaps _wp_staticize_emoji_for_email()
and _wp_staticize_emoji_for_feeds()
?
#64
in reply to:
↑ 63
@
10 years ago
Replying to pento:
If we want to chat about purpose before deciding on a name, it's worth considering that they're really just single-purpose filters (to be thin wrappers that filter content through
wp_staticize_emoji()
), so maybe they're better as_
-prefixed@ignore
-d functions?
Yes. Yes.
Perhaps
_wp_staticize_emoji_for_email()
and_wp_staticize_emoji_for_feeds()
?
Yes.
This ticket was mentioned in Slack in #core by pento. View the logs.
10 years ago
#67
@
10 years ago
- Keywords has-patch removed
- Resolution set to fixed
- Status changed from assigned to closed
*ksssshhhhtttt* This is your Emoji Captain speaking, it's been a pleasure flying you to Emoji Island, all of us here at x1f4a9 Airlines hope your stay is a pleasant one.
If you have any feedback for us, please open a new ticket at your leisure.
Note to self, for when it comes time to commit this: @batmoo, @joen and @mkaz are owed props for their work on WP.com's emoji support, upon which x1f4a9 is based.