Comment by cdmckay
2 days ago
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?
2 days ago
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?
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.
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 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.
Why is it a problem for web browsers?