[SahAssar]

iconfonts and unicode icons are two different things. unicode icons are the built in icons that renders correctly (but with slight variations) on any modern device, iconfonts are basically your own icons set as a font, hopefully using Private Use Areas for the codepoints.

[danShumway]

> on any modern device

This qualifier is why Unicode icons should be avoided where possible.

You're correct that Unicode icons are different from icon fonts in the sense that they're standardized -- but the standard doesn't matter unless everyone implements it; and as we can see on HN, plenty of platforms don't.

In practice, there are just too many platforms/devices that implement only part of the Unicode standard, or that implement it incorrectly, or that extend it with their own stuff.

[SahAssar]

HN just restricts the carachterset that you can use when commenting, just like they don't support inline images or links with customized clickable text. By that rationale we should stop using images on the web because "some platforms" don't allow them in their comment fields.

In practice unicode icons are widely supported enough to use.

[danShumway]

I don't think this is a very good comparison -- the difference you're missing is that if you embed inline images or custom links into a HN comment, they degrade gracefully into URLs that anyone can use.

  [click me](https://google.com)
  <a href="https://google.com">click me</a>
  <img src="thiscatdoesnotexist.com" alt="this cat does not exist" />

In HTML, if a browser doesn't support images, they also degrade gracefully into alt tags, which work with screen readers -- images can even be styled with CSS to avoid document reflows. This is common practice on platforms like email, where remote images will often be blocked.

I'm not saying avoid emoji, I'm saying avoid encoding them into a format that literally stops rendering or turns into an undecipherable mess the moment it's not fully supported -- especially since there are other encoding formats we could use that would be just as good as Unicode and that wouldn't have any of its downsides. In general, we should try to build escalators, not elevators.

[SahAssar]

> In general, we should try to build escalators, not elevators.

Agreed, but what is the better escalator in this case?

[danShumway]

IMO for most text-fields and markdown interfaces it's a shortcode.

  :smile: :calculator: :pikachu_brandishing_ketchup:

The only big downside to shortcodes are that they're more than one character long, but there's no good way I can think of to have screenreader-accessible emoji that doesn't contain a multiple-character description anyway.

Shortcodes will get passed properly through 99.9% of existing text processors without any problems, so it's a really safe format to store things in.

I think the conversion to pictorial form should only happen at the display layer. If you're writing HTML, I advocate for using an SVG with a title attribute. Unicode emoji are already SVGs, so the only thing that changes is you don't bundle your emoji into a font.

Even native applications understand how to automatically highlight things like urls with the `https://` `http://` format, so my personal vote is we just use shortcodes the same way we use URLs.