Markdown is the Unix of rich text formats.

Ready for Markdown wars?

You mean like original recipe vs. GitHub flavor vs. Reddit flavor vs. CommonMark? We're already there, dude.

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.

But nobody (relatively speaking) uses CommonMark, and everyone uses Markdown

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.

The hours I spent chasing down the edge cases with inline html! There’s some real nuance to the spec there.

You need inline html fairly often for anything non-trivial, and some of the rules certainly aren’t intuitive or easy to remember.

That said, like JSON, it won by being both simple to grok and good enough for most use cases.

> 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.

That sounds horrible. You should never mess with the semantics of standard shortcuts like that. Please let paste mean paste and not "smart" paste.

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.

Interestingly it annoys me when other tooling *doesn’t* do this

Google Chat is also somewhat terrible at it.

Want to italicize some text? Easy right, just do it like *this*.. nope that will bake it BOLD, gotta write it like _this_ for italics.

https://support.google.com/chat/answer/7649118

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.

And even HTML was not safe because <b> and <i> were too easy so now we have <strong> and <em> because somehow those are more meaningful.

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>.

I think one of Markdown's biggest mistake was making `*` and `_` interchangeable. It should have been `*bold*` and `_italics_` from the beginning.

I agree with you on that.

What about * for bold, / for italic and _ for underline?

/ 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.

True.

Perhaps //italic text// would be acceptable.

// is common in URIs.

You shouldn't parse '/' in foo/bar/baz or in foo / bar / baz.

If people want to make foo or foo bar italic, they write /foo/ and /foo bar/.

I have no regrets on this one. I thought people would use both, and people do use both.

HN uses *italics*.

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.

>having it in the raw form while typing

This is actually an option in the settings (on desktop, at least).

Aw that’s embarrassing. Thanks.

> 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.

> 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.

I was referring to the sentiment that “MD looks so good that I might never even render it”.