Add custom emoji spec#586
Conversation
|
|
||
| ## Emoji images | ||
|
|
||
| Emoji images SHOULD be a minimum of 128x128 pixels in size for raster images. This allows clients to size emoji appropriately in their UI without needing to worry about blurry images on high DPI displays. This specification does not dictate any particular file formats for emoji images, however clients SHOULD support static PNG and JPG images and MAY support any number of additional formats. See the client implementation considerations section for discussion on the security implications of supporting certain formats. |
There was a problem hiding this comment.
Allowing smaller images can be useful for pixel art style icons that would lose detail when downsampled.
There was a problem hiding this comment.
The spec already allows this (SHOULD is not MUST). Do you think there needs to be a mention in the considerations section as to when smaller images are appropriate, or is it good as-is?
This updated draft incorporates the following changes: - Removal of the +draft/emoji client tag. Correctly defining this tag would result in additional work in the client, and it renders copy/paste workflows more difficult as any clipboard operations would need to also include tag metadata instead of just textual content. - Removal of the suffix notation. With the removal of the client tag this notation no longer performs any useful function, and was confusing with regards to what it accomplished in any event. - Disambiguation of pack-id built into emoji syntax. With the removal of the client tag, pack disambiguation for duplicative shortcodes needs to happen inside the message content. An algorithm to resolve a shortcode to a pack id in the event one is not explicitly specified was also added to ensure clients agree on the same emoji object for such cases. - Shortcodes and pack-ids expanded to allow (almost) all Unicode characters. To make parsing easier, / is not allowed in shortcodes and : is not allowed in both shortcodes and pack ids. Other forbidden characters include whitespace, control, and text fomatting codes as allowing these could result in portions of a message outside of the emoji-value rendering differently depending on whether or not the shortcode was replaced. - The alt text guide was moved to a new pack author considerations section since it provides guidance on the creation of alt attributes rather than the usage of them. - Language allowing channel emoji packs to be shared between channels was added. - Guidance regarding multiline messages with multiline-concat was added to the client considerations section. Notably, an escaping mechanism was NOT added in this draft. It is likely to be added in a future draft, but there isn't clear consensus on what that mechanism should look like as of yet.
|
|
||
| 1. If the message is in a channel, look up the shortcode within the emoji pack document specified by that channel's `draft/emoji` METADATA. | ||
| 2. If step 1 fails to produce a shortcode mapping, look up the shortcode within the emoji pack document specified by ISUPPORT `draft/EMOJI`. | ||
| 3. If steps 1 and 2 fail to produce a shortcode mapping, an implementation MAY attempt to resolve the pack-id via other means (such as a local cache of known packs). |
There was a problem hiding this comment.
What's the point of this fallback?
To me it sounds like an interoperability issue, where different IRC clients could resolve emojis in different ways.
The specification provides an example of replacing :wave: with 👋, but I don't understand why couldn't the client simply replace :wave: with 👋 when sending the message.
There was a problem hiding this comment.
The client could certainly do that. I'm not going to mandate that clients do so in outgoing messages because it's impossible to specify in any clean fashion and there's no feature negotiation needed to make use of custom emoji.
The reason for the fallback is simple: I cannot predict where custom emoji may go in the future or what inventive things users and clients may eventually do with it, and the algorithm to resolve an emoji shortcode is a MUST with a strictly-defined ordering. This fallback offers an escape hatch to augment the resolution algorithm in the future, such as via a future specification which brings some additional optional features into custom emoji. These extensions would not be possible without this fallback without errata to this specification as well (breaking the ability for those extensions to be self-contained).
|
|
||
| ## Emoji images | ||
|
|
||
| Emoji images SHOULD be a minimum of 128x128 pixels in size for raster images. This allows clients to size emoji appropriately in their UI without needing to worry about blurry images on high DPI displays. This specification does not dictate any particular file formats for emoji images, however clients SHOULD support static PNG and JPG images and MAY support any number of additional formats. See the client implementation considerations section for discussion on the security implications of supporting certain formats. |
There was a problem hiding this comment.
It may make sense to recommend IRC clients to send HTTP Accept header with the list of formats they support when they send a request to retrieve emoji. This would allow IRC servers to, say, determine whether to send animated WebP file or a PNG emoji, depending on file format support.
Custom emoji can now only appear at the beginning of a line or after a space character. This solves a couple of issues with the current spec: - Lack of escaping. It is now easy to "escape" a custom emoji shortcode by simply embedding it within a larger string. For example, surrounding it by quotes. With this, I do not beleive any specific escaping mechanism needs to be specified. - Vexing parses like :foo:bar:, where clients would need to determine if they want to replace :foo: with an emoji or :bar:, because they are unable to replace both (only one colon in between). Assuming this string is at the beginning of the line or preceded by a space, the spec is now unambiguous that :foo: is what should be replaced with the custom emoji. If :foo: isn't a valid custom emoji, then :bar: will not be replaced because it is not at the beginning of the line and is not preceded by a space. - Multiple emoji can still be put in sequence provided the entire string of custom emoji is at the beginning of the line or preceded by a space, for example :foo::bar: is still valid and would result in both :foo: and :bar: being replaced.
7 participants
There's a lot here and is largely guided from some discussions in
#ircv3. Given the already-chunky size of the spec, I opted to omit any methods of programmatically managing the linked-to emoji pack JSON documents for clients to build emoji-management UIs (and for servers to maintain stricter control over URLs contained within the emoji packs). I'll be sending that up as a separate spec at some point in the future unless someone else beats me to it first.