The author addresses this too. Once you start down this path, you go down the road of non-standardization which means losing portability, etc. I don’t see how this is a point against the author?

None of the author's other suggestions are portable either. So what if pandoc markdown is only understood by pandoc's tooling? DocBook is only understood by DocBook tooling. The difference is that pandoc markdown is already 95% similar to every other flavour of markdown, so migrating to a new system (if necessary) would be relatively simple. Also, the difference is that XML is a pain to write and I'm not sure semantic tags matter all that much.

Maybe portable isn’t the right word. I read portable as meaning the format’s semantics are consistent across platforms. The way I read the author’s complaint was that once you start tacking on extensions to markdown, you run into the problem of seeing if other markdown platforms being able to support your variant of markdown. Hence the part about CommonMark vs GitHub-Flavored Markdown vs etc. Having actually run into this before when working on CMSes in the past, I get why the author sees this as a problem. I don’t think everyone will agree with the authors viewpoint, but I just happened to think that this thread is completely missing the point that the author is trying to make.

> I read portable as meaning the format’s semantics are consistent across platforms.

By that definition, a format which is only implemented on one platform is 100% consistent. I agree Markdown is uniquely fragmented, but it's also uniquely widespread.

Markdown is an extensible core for writing platform-specific languages. I think comparing markdown in general to something like DocBook is comparing apples to oranges. Instead compare (e.g.) Pandoc's specific markdown variant to DocBook.

> I think comparing markdown in general to something like DocBook is comparing apples to oranges.

Hmm let me rephrase the issue I have with the comments in this thread. If your position is that markdown doesn’t belong in the same category as the others, then yeah, I agree. But I also think that’s basically rejecting the premise of the article and there isn’t a discussion to be had. If you disagree with the core premise, then it doesn’t matter what is said, there’s no discussion to be had.

However, the original parent comment is stating that the author’s assertion is false because you can extend markdown. I don’t see how that logic doesn’t run into the semantics and “portability” problems that the author is writing about.

I think you can have the discussion, but you also have to be careful about how you have it. Markdown is a family of languages; if you want to evaluate markdown against something like asciidoc for a particular use case, you have to pick the members of the markdown family which are best-suited for that use case and evaluate those flavours individually.

Take the comparison between markdown and asciidoc. You can't say, "asciidoc has semantic structure and markdown doesn't," because pandoc markdown does have semantic structure. If you need semantics, you can use pandoc markdown, which is a very fully-featured language that suffers from none of the issues the author points out. Yes, other flavours of markdown exist too, but so what? This one has great tooling and suits your needs.

Of course, you can't use pandoc in (e.g.) Reddit comments. But you also don't really need semantic markup in Reddit comments. It's a different flavour of markdown in a different application that is solving a different problem. Or consider MDX: Yes, `Command` is a react component, but maybe it needs to be a react component. Maybe it has a "run this command" button, or it generates an interactive graph of some sort. If you mark that up in asciidoc, you need a whole separate system to attach your components to your markup. That's just using the wrong tool for the job.