I think a major pro of browsers serving content in a limited markup language (with Gopher being the extreme example) is that a variety of applications can realistically work with rendering them, without having to offload everything to a web browser.
I've been wanting to write a simple markdown renderer so that I can view my notes/todo in a nicer form without having to generate a PDF or open by browser, so I'm very excited to take a look at this codebase later.
> I think a major pro of browsers serving content in a limited markup language ..... is that a variety of applications can realistically work with rendering them.
I couldn't help but think of Gemini[0,1] and the number of applications already built for it[2] precisely because of the limited language. Gemini is an exciting space for lovers of a safer and lightweight internet.
It becomes clear that when rendering (and feature-bloat) are reduced, development begins to thrive. The Lagrange browser[3] is a great example of rendering not being an issue which gives developers time to build a great browser. For anyone curious, check it out to see what I mean: portable versions are available on Windows and Linux (appImage).
I have to admit that textual-markdown (OP) has me feeling the same way. I've been using command line browsers (on/off) for decades (since DOS). I don't know if I've ever seen a text-based browser look so beautiful. Wish the author the motivation and passion to keep this project going. I think it has great potential.
A better solution is just committing to simple HTML which is already supported in browsers. You get all of the free functionality of modern HTML with zero extra work.
Markdown lacks the ability to support arbitrary names anchors so it's difficult to provide links to a portion of a document that isn't a heading. It also has no ability to build HTML forms so you don't have any interactivity. It's also extremely limited for embedding media.
An application (remote, localhost, or whatever) can spit out HTML5 and get a lot of free functionality with an unmodified browser. HTML5 forms support input types so you get some free input validation. It supports displaying multiple types of media. Browsers also have a lot of accessibility features just built in and available with the appropriate markup. No JavaScript required.
Basic HTML is very functional all by itself. Any application wanting to use functionality beyond reading just plain text will run into Markdown's limitations. If most of what people actually want to do is blocked by Markdown's limitations no one will use it which makes the effort a bit pointless.
I use Markdown a lot, and the renderers I’ve used support embedded native HTML, so you can mix MD and HTML in the same document (and even style tags if needed), but you wouldn’t necessarily use that to build an entire form.
Markdown as source that gets converted to HTML isn't the issue. The issue is the suggestion that browsers support native Markdown rendering and sites just deliver raw Markdown content because "it's simple".
To your point, delivering raw Markdown to the browser means the browser needs to implement a renderer that supports inline HTML. If you're doing that you might as well just deliver that Markdown pre-rendered as HTML. Then you can be sure the browser will get the inline HTML that way it was intended.
Markdown is great for writing "plain" text that's perfectly readable by humans but can be trivially converted to some delivery format. It's not really fit for purpose as a delivery format.
This. I am content with this. I’m interested in an extremely minimal browser for MacOS that is just a box that renders HTML and CSS just to view notes inside of. Min may foot the bill.
IME Obsidian.md has become almost an OS for markdown files; it's extraordinarily capable and ergonomic. Highly recommend checking it out before building your own; then even if you still want to DIY, I expect you'll come away inspired.
Likewise, I have been using Zettelkasten method for my own notes written in markdown on the terminal. Which are then later searched/consumed/linked via search tools like ripgrep and viewed in the terminal.
These notes contain diagram code like plantUML/graphviz and mermaid. I have been resorting to also rendering them in ascii to still gain value out of them if viewed from the terminal only.
This should complete my setup where diagrams/math rendering and all code could be rendered together.
I think a major pro of browsers serving content in a limited markup language (with Gopher being the extreme example) is that a variety of applications can realistically work with rendering them, without having to offload everything to a web browser.
I've been wanting to write a simple markdown renderer so that I can view my notes/todo in a nicer form without having to generate a PDF or open by browser, so I'm very excited to take a look at this codebase later.