Don't print the emoji-detection script

[aristath]

The emoji-detection script is currently added on all pages in WP. That script was added for backwards-compatibility with browsers that (at the time) did not support emojis.
All browsers currently supported by WP have supported emojis for years so the script is no longer needed.I propose we remove the script hooks - but leave the scripts themselves for a while in core. This way if a plugin/theme explicitly needs to support a 15-year-old browser, they can manually re-add the hooks.
Alternatively, we could completely remove the scripts and all accompanying logic, and release them in the form of a plugin that can be installed and activated.

Note: This is already done in Gutenberg (see ​https://github.com/WordPress/gutenberg/pull/36765), so the attached PR does the same but on a wider scale.

Trac ticket: https://core.trac.wordpress.org/ticket/54530

[ocean90]

All browsers currently supported by WP have supported emojis for years so the script is no longer needed.

The script is not only used for checking if a browser has basic support for emoji, it also checks if the the platform does support the latest set of emoji. This way WordPress ensures that you can always use the latest emoji without worrying that it might not be displayed on some platforms which don't have an updated set yet.

[youknowriad]

@ocean90 Any ideas what these platforms are these days?

[youknowriad]

Oh It's about the yearly (or whatever) addition of new emojis. I wonder if loading the script is a price that is worth paying to support these additions consistently? Maybe it should be opt-in instead.

[swissspidy]

I'm -1 on the suggestion to not print it at all, for the reason @ocean90 mentioned.

It would be better to conditionally load the script (if there are any emoji on the page) rather than not printing it at all. Not that such an emoji detection would be much easier with FSE, and I think @westonruter wanted to look into that.

[desrosj]

I am strongly against this. As a component maintainer, I am going to close this as a won't fix as removing this wholesale is not an option as it would result in extremely inconsistent behavior.

Emoji is arguably just as important in modern communication as languages such as English, Spanish, German, etc.. 99.9% of users do not understand how Unicode works, how systems add support for new specifications, and if they were presented with a garbled character they would have no idea what it meant or how to fix it.

This change would also be against a ​number of the project's philosophies. Mainly "out of the box", "design for the majority", and "decisions not options".

One thing to keep in mind is that Emoji can also be in post comments, and other content printed on the page (such as from an external feed in a widget, etc.). So just scanning post content for characters to determine whether the script is needed is not a complete solution.

Improvements to how the Emoji detection script works are more than welcome, but this is a necessary technical feature to ensure sites don't seem "broken" to the overwhelming majority of site owners and visitors.

[aristath]

I agree that emoji is an important part of communication... But are there any browsers or platforms that WP supports, and they don't natively support emojis? Are there any examples of a scenario where the script is needed?

just scanning post content for characters to determine whether the script is needed is not a complete solution.

In block themes we know the HTML of the entire page before it gets rendered, not only the content but also headers, footers, sidebars, everything. Would doing this for block themes be a viable solution in your opinion?

this is a necessary technical feature to ensure sites don't seem "broken" to the overwhelming majority of site owners and visitors.

That assumes the user/owner is using a platform/browser that doesn't support emojis. Are there any platforms/browsers like that? Because I can't think of any - other than IE8/9 and things that are not supported in general.

[desrosj]

Replying to aristath:

I agree that emoji is an important part of communication... But are there any browsers or platforms that WP supports, and they don't natively support emojis? Are there any examples of a scenario where the script is needed?

The main scenario that this script is incredibly important is when new Emoji are added. It's a bit surprising because the script is now more important for forward compatibility than backwards compatibility.

This happens every year, and it's the responsibility of each system type to add support for new versions of Unicode. This often happens at wildly varying times, and some systems take nearly an entire year to add support. If a user has an older computer, they likely have software that only supports up to Unicode 11, 12, etc. and the number of characters that will appear garbled compounds. My personal machine, for example, is currently on MacOS Mojave, and can't update to newer versions. It will never support new versions of Unicode natively without me manually configuring that.

This can also currently be seen by ​looking at this page, which details the new Emoji approved and included in Unicode 14.0 approved in September 2021. You can see that most, if not all, of the new characters are displayed incorrectly. As far as I know, no systems support these characters yet, but it's expected some systems will start releasing updates adding support in the coming months. When Twemoji releases an update supporting new characters, WordPress can ensure that all site visitors can view all Emoji characters, regardless of what type of system they run.

just scanning post content for characters to determine whether the script is needed is not a complete solution.

In block themes we know the HTML of the entire page before it gets rendered, not only the content but also headers, footers, sidebars, everything. Would doing this for block themes be a viable solution in your opinion?

Yes, I'd be open to exploring this as that does seem like an improvement.

this is a necessary technical feature to ensure sites don't seem "broken" to the overwhelming majority of site owners and visitors.

That assumes the user/owner is using a platform/browser that doesn't support emojis. Are there any platforms/browsers like that? Because I can't think of any - other than IE8/9 and things that are not supported in general.

I think I covered this in the first answer.

[SergeyBiryukov]

Replying to swissspidy:

It would be better to conditionally load the script (if there are any emoji on the page) rather than not printing it at all. Not that such an emoji detection would be much easier with FSE, and I think @westonruter wanted to look into that.

Related: #41405

[Otto42]

#57880 was marked as a duplicate.