Hacker News Reader

Hacker News

Comment by cdmckay | Hacker News Reader

Parent Full thread

cdmckay

You could still support a subset of the most common features like bold, italic, strike, bullets, links, etc.

Isn’t the beauty of MD supposed to be that if you can’t render it it should still look fine as plaintext?

View on HN

Even these basics are not consistent. See my Markdown Monster:

https://git.sr.ht/~xigoi/markdown-monster/blob/master/monste...

There should be only one correct interpretation of that according to CommonMark. Software is faulty for sure and a lot of the these "markdown converters" are pre-AI slop code but at least there is a carefully written spec now.

(That dude who coined the name Markdown is being a dick about other people finishing his abandoned idea is another issue and not the fault of CommonMark.)

The problem for web browsers is that markdown is technically a superset of HTML.

Why is this a problem? To me it sounds like a it would be an advantage because you have everything you need to render it already built into the software.

Rendering is trivial. The issue is standards, and the DOM. No-one can write a Markdown implementation for the core of any major web browser in a form that is simultaneously acceptable to both their technical and political governance.

Best you’ll get is a plugin. Strictly arm’s reach. Translation only.

I'm not quite sure I understand what you are saying. Is the essence of what you are saying that it is hard to agree on a spec for the Markdown (and how it is translated to HTML or directly to DOM?) Or that this represents a technical challenge I don't understand?

I think you mean that any markdown byte sequence will also parse with some results using an HTML5 parser?

Content-Type should fix that.

Easy enough to associate *.md with one on most static servers too.

In what ways is it a superset? What can you express in markdown that can't be expressed in HTML?

Why is it a problem for web browsers?

Reply on news.ycombinator.com