Hacker News Reader

Comment by Johnny_Bonk | Hacker News Reader

I'm fairly new to all this, but my understanding is that Markdown is great for a few reasons:

It's just plain text, so no vendor lock-in and you can ripgrep/fzf/grep through it Lives happily in git repos with proper diffs LLMs speak it natively - they output Markdown, they understand Markdown input Way easier for agents to parse than PDFs (which are binary, layout-focused, tables turn to mush) Can do tables (at least in GFM), headers, code blocks, links - all structure preserved

What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering. Am I missing anything? What are the other limitations I should know about?

View on HN

(CommonMark) Markdown is a rough superset of HTML, like how YAML is a superset of JSON. So whatever can be expressed in HTML can also be expressed in Markdown. With the way the CommonMark spec is written, Markdown is effectively just an HTML preprocessor.

A major limitation of Markdown is the lack of standardization. For example, even within GFM there's multiple subtle variants: a single new line becomes a space when rendering Markdown files, but a line break in issue comments.

> whatever can be expressed in HTML can also be expressed in Markdown.

I suppose, since Commonmark specifically has HTML block and raw HTML inlines, any chunk of HTML is by definition valid Markdown.

It's enormously frustrating that there has been no standardization of the core base-level Markdown elements.

If you allow Markdown input you have to give a cheatsheet showing which "flavor" you are using.

I've started to "standardize" my own use of Markdown as "whatever works in the apps I use". For me these apps are iA Writer, Obsidian, and Astro's rendering pipeline (which uses the Remark/Rehype ecosystem under the hood).

This sucks for sharing documents with other people, but in practice it's not a problem. 99% of my writing never leaves my notes app or blog. And when it does, I often export it to PDF or Word to make it easy for non-techie people to read (I love Pandoc for this, it's easily one of the favorite tools in my daily toolkit).

That’s because Gruber shut down the effort to standardize markdown. He declined to participate and then demanded that “Standard Markdown” be shut down when it went public. This is what yielded CommonMark.

https://blog.codinghorror.com/standard-markdown-is-now-commo...

So we are left in the mode where markdown remains needlessly fractured. Different flavors that render slightly different and everyone gets a little annoyed but they deal with it ands occasionally bemoan the fact that there’s no standardization.

> What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering. Am I missing anything? What are the other limitations I should know about?

Multi-level lists, annoyingly, get rendered as code at the deeper levels because of the 4+ spaces from the beginning of the line.

This is a serious and major drawback of markdown, making it good for developers only. The average person does not want to render code.

Remove that one drawback, and it'll get even better adoption.

That's a "feature" of a specific renderer. I just went 22 levels deep with Zed and Marked, and both kept rendering each line as regular text.

>> The average person does not want to render code.

> I just went 22 levels deep with Zed and Marked

Sounds like you're agreeing with me :-/

Or are you arguing that the average person is a programmer, using programming editors and JS libraries?

I don’t follow. Marked definitely isn’t a programming tool. There’s nothing about Markdown that says nested lists should look like code. That’s just an accident of whatever editor you might be using, not of others.

> There’s nothing about Markdown that says nested lists should look like code.

Yes there is. The Common Mark spec, from 2014, says 4+ spaces indents are code. Nested lists go beyond 4+ indents pretty fast.

…as long as you ignore the context that it’s a nested listed under a less-nested list.

Also, note that CommonMark is not identical to Markdown. It intends to be a standard definition of the language, but may differ from the original definition and implementation.

> That’s just an accident of whatever editor you might be using, not of others.

And that’s the main issue with Markdown.

> Multi-level lists, annoyingly, get rendered as code at the deeper levels because of the 4+ spaces from the beginning of the line.

Not so. You just need to be principled with your indentation, adding four spaces or one tab for every level of nesting.

  1. Here is a thing.

      - See, it works.

          Nothing is amiss.

  2.  If you want to align everything…

      -   Then it looks like this.

          Then it doesn’t seem so weird.

(You can leave or remove the two spaces of HN code formatting; zero to three spaces don’t matter.)

I’m pretty sure many Markdown implementations would turn this into a code block. Unfortunately Babelmark seems to currently be broken so I can’t test it.

The original spec says it should work, and it does with <https://daringfireball.net/projects/markdown/dingus>, as with <https://spec.commonmark.org/dingus/>.

your markdown parser isn't compliant with commonmark: https://spec.commonmark.org/0.31.2/#example-294

indented code blocks are leaf blocks, while lists are containers that take precedence

> What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering.

Please see:

* https://impacts.to/downloads/lowres/impacts.pdf

* https://keenwrite.com/docs/user-manual.pdf

* https://keenwrite.com/blog/2025/09/08/feature-matrix/pdf/jek...

* https://keenwrite.com/blog/2025/09/08/feature-matrix/pdf/sof...

Those are Markdown documents typeset using ConTeXt. Except for Jekyll & Hide, I wrote them all.

> What are the other limitations I should know about?

It's completely inadequate for anything more than a memo or simple single-page note. Which is fine for many purposes a typical software developer encounters but quickly gets left behind for anything more.

It's exclusively a markup language, completely lacking in semantic meaning. If you're trying to write an actual document, the title is the title not some bold text in a bigger font, for example.

Like a hammer, it's a great tool for certain jobs. So many people assume all their writing tasks are nails.

> What it can't do (as far as I understand): complex layouts, precise typography,

Some "extended" flavors will allow you to embed HTML and CSS which solves the layout problem. It's not really markdown at that point, though.

> embedded binary content,

If you're using one of the extended variants, you can b64 encode images... but again, that's not really the spirit/intent of markdown.

It’s not just “extended” flavours of Markdown that allow embedding HTML. The original reference implementation supports this too.[0]

> For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.

[0] https://daringfireball.net/projects/markdown/syntax#html

However, there is no way to switch back to Markdown inside HTML, so if, say, you want to have an <article> tag around your article, you need to write it entirely in HTML.

Off the top of my head: Math typesetting, semantic markup, small caps, document sectioning. (All of these things are very important for me.)

The mistake people do is thinking markdown is something else than a text file formatting convention that is easily converted to other formats to make it prettier.

If what you want to do can't be done by a text file hosted on a gopher server, it just means markdown is not for your usecase.

Markdown is not meant to replace Latex or Microsoft Publisher.

The lack of viewers for it.

Reply on news.ycombinator.com