[wp-trac] [WordPress Trac] #61806: twemoji is always loaded on Windows devices

[WordPress Trac]

#61806: twemoji is always loaded on Windows devices
--------------------------+------------------------------
 Reporter:  Clorith       |       Owner:  pbearne
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Emoji         |     Version:
 Severity:  minor         |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+------------------------------

Comment (by dmsnell):

 > The three emojis at the end of your message are indeed showing as a
 blackbird, then a red bird with a black square following it, but they're
 also all replaced by the img tags.

 Case in point 😄

 [[Image(https://cldup.com/E7ktIQFF_F.png)]]

 No red bird over here. To be clear, though, @Clorith - are you seeing
 image replacement here on Trac? If you are, then maybe there's something
 in your browser? Because Trac involves no such emoji replacement. Maybe
 you copied and pasted these into a WordPress document? I was asking
 specifically about how the Emoji render in Trac, where no such script
 runs.

 > it would ideally have the same emoji and visuals in the back-end and
 front-end

 This is a good point, though also complicated. I'm not sure of what impact
 or technical challenges there would be for replacing text in the editor
 with images. Presumably, an author would not be writing unsupported emoji
 on their computer.

 > surely when a block is not in edit mode, it would be in display mode

 It's not so much edit vs display mode here. The Twemoji script is only
 intending on handling cases where a browser isn't able to render the
 Emoji. Normally it won't kick in for modern computers with modern
 software. Something on your system is telling it that it's failing to
 render.

 > In an ideal scenario, the twemoji script would look up any emoji used on
 a page, and only replace the ones not supported

 Yeah this has been brought up, though each additional bit of complexity
 increases the burden on //every page load//. I think the compromise today
 (and this is something more that @westonruter can probably confirm) is
 that //if// a browser is lacking any of the given support, it should load
 Twemoji, otherwise don't burden the vast majority of page views by loading
 things that might not be necessary.

 I'm not familiar with Twemoji or if it's possible to split it into
 different levels of support. That'd be a good avenue to explore, as it's
 quite common for browsers/OSs to lag support for the newest Unicode
 standard, when that might only involve a handful of new Emoji which are
 unlikely to be on the page itself.

 Still, processing a page to find unsupported Emoji might be quite costly,
 and in some cases not possible. The emoji-loader script relies on some
 canary tests that only work because they are multi-character sequences,
 and those sequences don't combine when unsupported. Single-character Emoji
 may not provide any reasonable way to know "is this rendered properly?"

 @westonruter - did you explore comparing the render of an Emoji against
 the replacement character `�`? I know that //some systems// don't use
 that, instead rendering the box with the code point inside it. For
 example:

 [[Image(https://cldup.com/yxvjznh1g0.png)]]

 ----

 My guess is that there's something affecting text rendering in your
 browser and it's causing the script to misdetect. Something that causes
 one string to have subtle differences: like even a pixel or sub-pixel
 difference between the real grapheme cluster and the detection cluster.

 What do you see if you navigate to this test page I made? It runs the same
 tests that the emoji loader is running, but instead of making a decision,
 it visually displays the comparisons.

 https://s.xkq.io/emoji-detection.html

 Here's what it looks like on my computer. It's not the most elegant tests,
 but if the "Drawn Text" matches the "Drawn canary" then it determines that
 the Emoji //isn't// supported.
 [[Image(https://cldup.com/1j2GfrgfOp.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61806#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform