Good luck getting the browsers to implement anything so useful. They won't even update their default stylesheets.
I set up my blog with that kind of mentality - I just want to write some markdown and have the browser render it whatever way it needs to - and found a one-liner to pull in some Javascript to do that. But the kind of people who like this stuff tend to hate Javascript, so I get it from both sides.
I don't use other browsers so I can't be sure if this is widespread, but Firefox already has a "reader mode" where it cuts out ads/sidebars etc and applies its own very basic stylesheet. Markdown-over-HTTP could very easily use that preexisting frontend.
> I set up my blog with that kind of mentality - I just want to write some markdown and have the browser render it whatever way it needs to
I made my own blogging platform where I write Markdown, and it transforms the markdown into HTML before delivering it to the client. The only JS involved is highlight.js, and that's only loaded on posts where I specifically ask for it - the whole blog works normally with no JS at all. It's still missing some core features like RSS, but I'll get around to that.
> I made my own blogging platform where I write Markdown, and it transforms the markdown into HTML before delivering it to the client. The only JS involved is highlight.js, and that's only loaded on posts where I specifically ask for it - the whole blog works normally with no JS at all.
There are plenty of platforms that will render markdown into HTML (e.g. Jekyll); I specifically wanted to actually serve the markdown as-is, so that the "source" for any post is always available.
I've thought about adding this to my own platform. Just checking the Accept header for text/html or text/markdown, then sending them whatever they prefer. I just don't know if anyone would actually use it.
Gemini is like modern Gopher, but it is also very opinionated. The protocol does not support extensions and revision, it refuses HTTP, mandates TLS, etc...
That's not the same as having browsers support the markdown content type.
You might disagree about where to draw the line but you can see why they drew a line in the sand. text/markdown would very quickly grow to be everything HTML is.
There's probably a pithy "every internet protocol expands until it can serve ads" lesson in there somewhere.
I just stole it from jmz - "every program attempts to expand until it can read mail" - I think attribution might be overkill. But thanks for the thought.
This used to be something one could sketch up in a couple hours on the web, with registerContentHandler.
Removed in 2018. I don't totally disagree with the reasoning, but when the web kills amazing flexibility points for lack of heavy adoption it makes me sad. There's so many good ideas that should be left in, even though society isn't actually so bloody awesome as it should be. https://groups.google.com/g/mozilla.dev.platform/c/jeTDLz38_...
Also, scoffing at 0.2% of users of a web browser is multiple orders of magnitude away from where the line should be; these people are a fucking joke & shame the fuck on them, losers. Jonathan Kingston, what the heck dude? What the frelling heck?
Also no other browsers implemented it! Adoption needed help! Not to be murdered.
Tl;Dr, adding new content types used to be easy & simple & you could register a site as a content handler but they always kept the feature locked down then killed it without ever letting people go for it at all. Gatekept.
I’d prefer everything to have the same syntax, like in HTML (or I should better say XML).
When every feature has different syntax, like in Markdown, it makes parsers much larger and leads to an extreme amount of edge cases that every parser has to handle. For example, when you see an asterisk, you have to decide whether it denotes italics, bold or a bulleted list, which might not be trivial.
Generating correct Markdown from a different is also much harder. In HTML, you just need to escape all your less-than signs, ampersands and quotes. In Markdown, you need to check whether your content is going to trigger various edge cases and deal with them accordingly.
Markdown's complexities reside almost entirely within its syntax, sure. There would have to be some kind of formal grammar, or a very, very deep suite of test cases. Without a formal grammar, you introduce risk through ambiguity. But, Markdown's scope is relatively limited, so that risk is unlikely to result in catastrophic failures (as long as you disregard that whole "embedded HTML" thing).
generating Markdown is tricky, but that's fine. In this scenario, Markdown would be hand-written and machine-read. There are plenty of use cases where Markdown wouldn't (and shouldn't) replace HTML, and "computer-generated web pages" is one of those use cases.
I think the biggest hitch would be metadata. A lot of Markdown parsers have support for a YAML header, but that behavior is heavily implementation-dependent (even relative to other markdown features). Coming to a consensus on this could get ugly.
Yeah, I guess that's a really good point. I've never thought much about it before, but you're right that the simplicity of markdown is probably more from the point of view of the human writer/reader, and is really just passing the complexity down to the parser.
You don't need to escape all your ampersands and quotes. An ampersand that doesn't form an html entity will render as is, quotes are perfectly fine unless used in an HTML attribute. And in an html attribute, less thans are fine. The body of a script tag has different parsing rules.
You don’t need to escape them, but it certainly doesn’t hurt. And script tags are generally not a problem when building something from a template, but they are a reason why XML is more “pure” than HTML.
