Emoji line-height Adjustment - Feedback

Experiment Paused :pause_button:

This topic is dedicated to gathering feedback, primarily focusing on any UX-related issues, for the ongoing experiment in which emojis no longer affect ‘line-height’ and also respect the user text size setting in topic posts, messages and chat.
For instance, you can find an example, here… :slight_smile:

Without the experiment at the Smallest user text size (the most dramatic difference):

^ It appears there is a line break before “For instance,” while there is not.

Why is this an experiment and not simply a bugfix?

It could be, but there are potentially present hidden issues across different devices, browsers and operating systems. Safari, for example, renders the styling property of transform: scale(x) as blurry given particular digits and font-size combinations, with the webkit alternative being grow – but this property adds a marginal space to line height, unlike the more widely adopted property. This topic exists to throw a net capturing any bugs, before adopting support.


Nice! :slight_smile: The details make a difference.

I did a few tests in different platforms and browsers; it looks good so far!

What about applying a similar logic to the emoji in the title?
I can see admins customizing their theme and increasing the font size.



1 Like

This feels related @tynaut


Did user status styling get impacted by this?


Confirmed. This was fixed with chat specifically.

But for posts/messages, I’ll look for a fix on that selector. It needs to be wide enough to capture emojis in dynamic <li></li> (as an example) or any markup but specifically not certain things.


This experiment has currently been paused/disabled 2024-01-02T06:00:00Z until the foreseeable future, to diagnose rendering issues with Safari that are related the transform: scale(x) property; emojis may appear blurry in random cases, where they may render crisp in one post, the next may appear blurry with no reproducible pattern.

Generally the rendering was accounted for with Safari, but as this inconsistency is harder to work around, this experiment will need a more consistent fix to go ahead with implementing and still support Safari’s version of webkit. I am leaning towards reimplementing webkit’s alternative grow property specifically for Safari. Even though this does consume a portion of line-height, this can be mitigated.