Emojis are sometimes used in plain text like list markers. That is, a single emoji (which may be a ZWJ sequence, flag sequence, etc.) is, except for indentation, the first character at the start of a line, with at least one space following and then some text (which may also include emojis). In other words, they effectively work just like -, * and +.
It may make sense to support these in an extension.
Aren’t there cases where emojis are used at start of sentence naturally, with no items structure intended?
Are future emoji codepoint known ahead of time (for at least couple years)? If not, it means implementations would disagree about block structure.
What about combining emojis? Things like "female painter tone 3" that users perceive as single emoji may consist of several codepoints combined. Do we want to require parsers do understand enough Unicode for this?
What do you think of a convention inspired by github’s - [x] checklist syntax, where you’d still use a standard list character followed by an emoji?
- ✅ done
- ❎ open task
Then you replace the bullet during rendering. This would degrade better with parsers that don’t implement this extension.
That discussion is related for sure, but I would expect emoji lists only ever as an optional extension, whereas some people at least want the Bullet character to be a first-class list marker in Commonmark.
I linked to the document specifying the various kinds of emoji sequences in my initial post, because I agree that an emoji is what most people perceive as a single one.
In theory, any existing character could be made an emoji retroactively, but in practice that will hardly ever happen again except when preceded by ZWJ U+200D and followed by VS-16 U+FE0F, i.e. as part of a sequence, and then mostly for pictographic or symbolic characters, especially those in U+26xy. Otherwise, the SMP blocks to be used for future emojis are usually known several years in advance, but not the actual assignments. In rare cases, characters may be introduced in these blocks without receiving the Emoji property.
Single emojis may occur at the beginning of a sentence or paragraph naturally, of course, but I think the harm of interpreting them as list markers in an optional extension is rather limited.
The workaround with existing list markers as in GFM checklists works, but I would hesitate to actually require it.
In terms of the value that this provides, is the benefit of using an emoji list marker over a standard Markdown list marker mainly aesthetics? It seems that from a composition point of view using an ASCII list marker would be simpler since the writer doesn’t need to select the marker from a menu of emojis.
My motivation for this topic is standardization of what is already out there. People sometimes l use emojis deliberately as/like list markers in plain text. They do not put a punctuation mark in front of them.
A lot of sources generate Unicode bullet characters for lists, like pasting from MS Office. Others are enumerated earlier in that thread. Being able to use that text without modification is the founding spirit of Markdown.
that users perceive as single emoji may consist of several codepoints combined. Do we want to require parsers do understand enough Unicode for this?
Ha, nice.