No, I don’t agree @cirosantilli there are already so many ways to make lists:
* this is a list + this is a list - this is a list
So why not unicode bullet? Seems rather safe and minor of a change to me and it would help real users I see doing this in the wild a fair bit. That’s the main thing I care about. The combination of “easy, minor” and “seen in the wild a lot.”
Causal writers who do not know how to insert • may be confused when editing someone else’s unicode bullet list.
*+ and - are all easily accessible from a standard keyboard. Pressing Option+8 on the Mac to insert an additional • list item is not intuitive. If the writer does not know the key combination then they must use copy/paste, search for how to insert •, or rewrite all of the existing list markers.
No other Markdown syntax requires knowledge of key combinations (besides Shift of course).
I’m still on the fence for this change. So I’ll voice my thoughts for and against, and see if anyone can sufficiently shoot them down.
IIRC, all special characters in Markdown are in the ASCII range. Adding support for U+2022 would require that conforming implementations support unicode rather than ASCII, making the standard more restrictive.
Limited support from existing implementations. If they didn’t need it before, why do we need it now?
More divergence from the original markdown.
This particular change seems like it belongs in a unicode extension. Which could add all relevant unicode bullet characters to the list of acceptable characters, including (but not limited to):
• (U+2022) bullet
‣ (U+2023) triangular bullet
⁃ (U+2043) hyphen bullet
⁌ (U+204C) black leftwards bullet
⁍ (U+204D) black rightwards bullet
∙ (U+2219) bullet operator
◦ (U+25E6) white bullet
Additionally, unicode numerals beyond 0-9 could be supported for numeric lists.
on the other hand
“making the standard more restrictive” isn’t a strong argument. Unicode support isn’t particularly difficult when the character sets are well defined.
Many existing implementations don’t have support for fenced code blocks either, but utility was favored over popularity to reduce ambiguity.
Divergence from the original markdown is almost unavoidable, as the original is practically abandonware. If the original were to use semantic versioning, it’d be 1.0, and this would be the 2.0 spec due to the known API incompatibility.
Why go through all the extra effort to define the unicode alternatives to the core characters and then leave it up to implementors to choose whether or not they should implement an optional extension? Adding the unicode alternatives to core could help to make markdown more portable between conforming implementations.
Just wanted to note that this is not a valid point. There are two cases - either the particular implementation supports some kind of Unicode text encoding (like the C reference implementation supports UTF-8) or not (where it supports only ASCII).
If the supports just ASCII then there is no problem since the input data cannot contain a Unicode bullet char.
If it supports Unicode then the change to support this is trivial (as shown by the pull request).
Also note that the specification already contain tests that verify correct handling of Unicode characters (for url-encoding and tab expansion).
Common “in the wild” use case: Bullets are often generated when pasting text out of certain popular word processing programs.
WRT the awkwardness of input: Mobile OS (tablets, initially) soft keyboards will increasingly be used for Markdown. It’s fewer keystrokes. See http://www.emojitracker.com/ to address any concern about popularity of characters not appearing on hardware keyboards.
Can you explain how it addresses the issue I raised earlier regarding appending list items to other people’s unicode lists?
“Confused” seems like a broad assessment based solely on a very specific presumed configuration of ignorances, I guess. I’d expect someone editing a document with bullet characters to either copy and paste them if they felt insecure about the format, or else replace them with their favorite Markdown bullet characters.
It just wouldn’t help if the user opens an existing Markdown document that uses •. For example, if the Markdown document was created using an app which does not support the conversion of • to * (when pasting). Requiring the *-, or + character to be what is saved means that all users get to work only with bullet characters that are available on a standard keyboard layout, the lowest common denominator.
“Manually” replacing can also refer to whatever search and replace functionality the editor provides (though stock browser textareas in particular could require copying and pasting into another application for this), which is much less onerous.
There a lots of options for how the user could go about updating the list, some very efficient if you know the right commands and menu options. My concern with all of them is that they require extra knowledge of text manipulation that goes beyond the characters visible on a standard keyboard layout.