Because web browsers are supposed to render HTML, not markdown.
When presented with a file full of markdown, how should the browser present it? As a webpage? PDF? Plain text? Something else?
Once that format is chosen, markdown doesn't have any way to control that presentation. Black text on white? Opposite? Something else? How wide should paragraphs be? Each author and page has different preferences and requirements.
That's not considering the dozens of flavors of markdown, each with their own extensions, features, and subtle edge cases. See XKCD on standards: https://xkcd.com/927/
20 years ago, people were trying to make web pages out of XML. It didn't catch on. Markdown, likewise, has some pretty obvious pitfalls and feature deficiencies compared to HTML.
Check out The Gemini protocol. It is based on “gemtext” which is a flavor of markdown. The browser is responsible for determining how to render it. https://gemini.circumlunar.space/
For sure, I think other people answered that pretty fully. Was just showing you a cool little protocol where they decided markdown was the format of choice.
docsify [1] takes that approach. It's a tiny HTML file with a chunky JS script that fetches Markdown files and renders them. It doesn't work if JS is turned off and it's probably less accessible than if the browser natively understood Markdown, but it is an approach to building documentation sites.
One of the strongpoints of Markdown is that the browser doesn't do anything with it. Therefore it's safe to just send it to the client.
If browsers started supporting Markdown then they'd inevitably extend it with autoloading resources. This would lead to Markdown XSS attacks. This would lead to developers needing to sanitize all markdown from untrusted sources, as well as scanning blocks of text for inline markdown that could cause problems.
That sounds like a stretch, but it's a well worn path.
And so ... if a given markdown author finds that some commoly used browsers don't render things the way they want (or a different subset of browser does the right thing when they fiddle with the markdown, never reaching a happy consensus), they will just throw up their arms and use their mardown->HTML converter of choice.
Have to agree there. But the purpose is HTML, PDF is a historical artifact (or list your reason why that should make sense and not this...), blah blah. People can come up with some very interesting ideas about why something unnatural is great (WASM and the nutty ideas some have about that) and why something like supporting an extremely popular static doc format is "out there".
The sort of stagnation we are seeing is IMO caused by the fact that being original and subversive involved finding new 'places' to try out new ideas, where the community is small and more amenable to trying random things out to see what happens.
Systems like Mastodon and IPFS should be trying out new structures and new protocols. In particular IPFS, because it's content without a server.
Browser developers should love Markdown because it's ill-defined, and so they could go to town trying to detect which quirks flags to enable for a given piece of Markdown that doesn't identify what version of Markdown it's using.
Would there be syntax highlighting?
```c
int main(void) { }
```
The more RAM and modules required to render a page, the merrier!
How about styling? People style the results of markdown by targetting the HTML conversion with CSS. So you're going to have to define a correspondence between markdown and the DOM in order to do that.
36 comments
[ 60.8 ms ] story [ 216 ms ] threadWhen presented with a file full of markdown, how should the browser present it? As a webpage? PDF? Plain text? Something else?
Once that format is chosen, markdown doesn't have any way to control that presentation. Black text on white? Opposite? Something else? How wide should paragraphs be? Each author and page has different preferences and requirements.
That's not considering the dozens of flavors of markdown, each with their own extensions, features, and subtle edge cases. See XKCD on standards: https://xkcd.com/927/
20 years ago, people were trying to make web pages out of XML. It didn't catch on. Markdown, likewise, has some pretty obvious pitfalls and feature deficiencies compared to HTML.
Ok but they could also render Markdown.
> When presented with a file full of markdown, how should the browser present it?
Render it on the screen.
> Black text on white? Opposite? Something else? ...
The browser can pick a sensible default, just like it does with HTML. How do you think GitHub manages to render Markdown? It picks a sensible default.
> That's not considering the dozens of flavors of markdown
Send the flavour in the MIME type. (Not sure we have MIME types for different flavours, but we could do that.)
Well, they render HTML, XML, XSLT, plain text, images, videos, even PDF nowadays
The Lagrange Gemini browser does render markdown as well as gemtext, but that’s a non-standard feature.
You'd also probably need an extension to Markdown that links it to a style sheet, so there's yet another dialect.
And then you'll want metadata, so ... which format do you support? Hugo's? Jekyll's? Something else?
Turning Markdown into HTML is (often) trivial. Turning it into a web page is often not.
The most popular one that doesn't do something extremely stupid, with a piece of version info in the http header mime type in case it's a mistake.
> You'd also probably need an extension to Markdown that links it to a style sheet, so there's yet another dialect.
Absolutely not. Let the user have a local style sheet to render it how they want with 1-4 sensible defaults much like FF reader mode.
> And then you'll want metadata, so ... which format do you support? Hugo's? Jekyll's? Something else?
None of the above. Just the markdown.
> Turning Markdown into HTML is (often) trivial. Turning it into a web page is often not.
Don't turn it into a webpage then, we already have those. Just render some markdown.
Myfile.html: <script>loadMarkDownFile()</script>
Myfile.md: ## Markdown in the browser!
[1] https://docsify.js.org/
Which is already the correct thing to do. It's a plain-text format, and browsers shouldn't be in the business of figuring how to render MarkDown.
What's next? AsciiDoc? LaTex?
[1]https://www.google.com/chromebook/chrome-os/
as well as rss: https://addons.mozilla.org/en-US/firefox/addon/rsspreview/
Edit: The markdown extension did not function as intended.
If browsers started supporting Markdown then they'd inevitably extend it with autoloading resources. This would lead to Markdown XSS attacks. This would lead to developers needing to sanitize all markdown from untrusted sources, as well as scanning blocks of text for inline markdown that could cause problems.
That sounds like a stretch, but it's a well worn path.
I don't like markdown or wikicode but browsers accepting a document format (any format) that is just a static document would be great.
Systems like Mastodon and IPFS should be trying out new structures and new protocols. In particular IPFS, because it's content without a server.
Would there be syntax highlighting?
The more RAM and modules required to render a page, the merrier!How about styling? People style the results of markdown by targetting the HTML conversion with CSS. So you're going to have to define a correspondence between markdown and the DOM in order to do that.