Emoji issue when rendering on webkit - Issue with how HTML is rendered

[awesomerobot (Kris)]

@Crius

Why is discourse assuming that every emoji is going to be “20x20”

That’s because all the standardized unicode emoji are meant to fit into a square, and we assume sites want their emoji to be sized consistently in a way that works alongside text and other emoji if that teapot was 50x50 it would put a huge gap between lines like this:

@Crius

enforcing it via html attribute instead of using CSS?

There’s a good explanation from when it was originally added:

Add lazy loading for emojis

Personally I think it is like a good manner to always add width and height attributes to img elements on point where the img-element is generated. That is the place where I might know for sure which exact image-file I’m putting in. CSS is far away from the actual image-file. On top the browsers use this extra info about the image size to calculate aspect-ratio before loading the image file - and before CSS parsing. For this case the emojis are used in many different places - and sometimes def…

With supporting details from Multimedia: Images - Learn web development | MDN

When the width and height attributes of an image are included on an HTML <img> element, the aspect ratio of the image can be calculated by the browser prior to the image being loaded. This aspect ratio is used to reserve the space needed to display the image, reducing or even preventing a layout shift when the image is downloaded and painted to the screen. Reducing layout shift is a major component of good user experience and web performance.

…

While developer best practices from the last decade may have recommended omitting the width and height attributes of an image on an HTML <img>, due to aspect ratio mapping, including these two attributes is considered a developer best practice.

All that said, you’ve got a reasonable example of a case where the default sizing won’t work for all emoji… that old cheers emoji is 3x as wide, so it doesn’t fit nicely in a square. It’s not unusual for other apps to limit all emoji to squares so we’re not too unusual in our behavior here (both Slack and Discord do it, for example)… but alternatively we could considering allowing custom emoji to optionally have dimensions set.