1. Apparently simple enough to implement to get the basics right (not that I could do it)
2. But there is plenty of room for accidental edge cases in the implementation
3. Many then implement it with or without edge cases
4. But it’s not enough because a lot of the people who use it are programmers so they naturally want to extend it to do just a little more
5. Now the standardization effort (Commonmark) has to take all of those edge cases into account plus have to figure out how to deal with extensions (especially for popular ones)
6. Then you get a heroically (in terms of effort and grit) wordy standard
All for the initial idea which is so simple that it seems redundant: look as good plain as rendered. (Then what’s the point of rendering it, and in turn what’s the point of a formal syntax instead of the (still existing) ad hoc email and whatnot conventions?)
Right now it’s fantastic for chat applications (here you definitely want rendering and not the visible markup). It’s been pretty good for things like forum comments as well. With the exception of block quotes which are a pain to fiddle with (the only prefix syntax if you don’t include the indentation-for-code since that is de facto optional now that so many applications support code fences… all because that’s how email does it).
To be fair, John Gruber offered up a completely deficient “standard” and a buggy as hell Perl parser implementation. Yet still wears “I created markdown” as a feather in his cap, strongly insists to this day that it was a good idea, and says “the canonical markdown docs are on my blog! Nothing else is markdown!” Things like CommonMark were absolutely integral to Markdown’s current success. It was way more about fixing John’s mistakes than adding more functionality.
They're not separate things, but a more consistent implementation of the original idea. GitHub, GitLab, Reddit, Stack Exchange... they're all adhering to CommonMark specification, not the original Markdown specification.
> 3. Many then implement it with or without edge cases
> it’s fantastic for chat applications
Slack is the absolute worst at it; I am unable to at all figure out what its "parser" (which feels like cobbled together regexes … but even then … not?) is doing.
[link text](URL)
is sometimes a link. But sometimes not! Sometimes Slack mutates your message, and then renders the mutated version — and this is visible if you subsequently edit your message, as what is now there != what you type. When it works it is nice, but when Slack decides it doesn't like that message, in particular, it can just be a pain to get it to do what you've typed.
Worse to me is that Slack considers "we mutated the input you typed, and then proceeded to misrender it" as "Won't Fix/Working As Intended". (I reported it a while ago, that was the resolution.)
fwiw, I find it's easiest to copy a url to my clipboard, go back to slack, type the words, then select them, and then hit ctrl-v, which doesn't get rid of the text but instead makes it a link with the selected text as the link text and the pasted text as the url.
This is very common feature of rich-text (and markdown) editors. GitHub comment boxes do the same thing even though they are not WYSIWYG. Confluence and Notion do too.
The only thing I like is that you can colorize text, but there's no syntax for it, you gotta highlight it then choose a color in the formatting toolbar.
It's annoying to no end when you memorized the syntax and Google decides to not even follow it.
Way back in the day when I was on IRC, I usually read them as,
*bold*
/italics/
_underline_
… which would have made sense, if you stop to think about the characters. (But of course humans are wibbly-wobbly in what they'll choose, so context is context.) Alas, bold is now different in everything, it seems, and I can never remember which is which, aside from Discord which gives visual feedback.
The worst part of the <i> to <em> migration is now <em> often gets used for book titles, which is completely wrong. Book titles aren’t emphasized, they’re italicized.
If someone hits control+I, or an italics button, it should use <i> tags, not <em>.
/ is too commonly used, such as when making a list of replacements/alternatives/synonyms. It works fine when it's just the text as written, but if it was parsing and turned that list to replacementsalternativessynonyms, it would only be getting in the way.
I, myself, prefer /italics/, _underline_ and _bold_ in text, if there is no formatting. I feel that these 2 are the least arbitrary, they almost work without agreeing on their meaning beforehand.
Slack is pretty bad yeah. It might work great if you write a whole message perfectly without typos. Then immediately when you have to go back and edit things like code snippets it gets confused: often you get raw backticks in the rendered message since it’s so confused.
And for technical stuff I very often have to edit my message.
And yes: don’t even get me started on having to think about whether I can write a link or whatever in MD or if I have to use the bells and whistles buttons in Slack.
Considering that Slack is used by both technical and non-technical users they should, well, really have a way to toggle between rendering the text immediately while typing and having it in the raw form while typing. Because editing it raw would be much less confusing for me.
> All for the initial idea which is so simple that it seems redundant: look as good plain as rendered. (Then what’s the point of rendering it, and in turn what’s the point of a formal syntax instead of the (still existing) ad hoc email and whatnot conventions?)
It's intended to look as good as possible in both mediums. It is not possible for the raw text to look as good as the rendered text and still be easily writeable, because the raw text cannot generate visual hierarchy using font size and weight.
I suspect you know this, but when you say readable raw text seems like a redundant idea, I'm not sure what point you're trying to make.
1. Apparently simple enough to implement to get the basics right (not that I could do it)
2. But there is plenty of room for accidental edge cases in the implementation
3. Many then implement it with or without edge cases
4. But it’s not enough because a lot of the people who use it are programmers so they naturally want to extend it to do just a little more
5. Now the standardization effort (Commonmark) has to take all of those edge cases into account plus have to figure out how to deal with extensions (especially for popular ones)
6. Then you get a heroically (in terms of effort and grit) wordy standard
All for the initial idea which is so simple that it seems redundant: look as good plain as rendered. (Then what’s the point of rendering it, and in turn what’s the point of a formal syntax instead of the (still existing) ad hoc email and whatnot conventions?)
Right now it’s fantastic for chat applications (here you definitely want rendering and not the visible markup). It’s been pretty good for things like forum comments as well. With the exception of block quotes which are a pain to fiddle with (the only prefix syntax if you don’t include the indentation-for-code since that is de facto optional now that so many applications support code fences… all because that’s how email does it).