Thoughts
All the fricking "just use a subset of HTML" people do not understand how hard parsing HTML is.
You basically would have to say "any attribute is not allowed" and then allow clients to throw/abort on anything that had element attributes. I kind of want to try this now, and write a minimalistic HTML spec page, satirically. Like just make it 50,000 words listing all the things you're not allowed to do.
You would have to aim for "miniwebsites" that could be accessed by Chrome. But I really do not think you could design the spec in such a way that miniweb-browsers would be able to read any HTML pages that weren't designed for the miniweb. You couldn't have that as a design priority.
Wait frick HTML links are `a` elements that require an `href` attribute. So now you have to support attributes. Like show me a regular expression that can hope to parse a single HTML element.
Okay, okay, you probably don't follow. For an example, given `<a href="..." tabindex=0>Click me</a>` is pretty common. See the problem? Even if we can parse attributes, a naive attribute parsing approach assumes the attribute is surrounded by quotes. But quotes are optional. And if you don't have quotes, it's hellish to find where the attribute parameter ends. Oh not to mention a lot of the time you don't have an `=` at all.
I've said before, I still don't understand the rules by which HTML collapses whitespace.
HTML and Gemtext are just not in the same galaxy. It's like walking into a conversation about markdown and saying "why not just use HTML". Except that HTML is still HTML and Gemtext is about an order of magnitude easier to parse than Markdown. Like, no one knows how to parse Markdown.
If you asked me to write a Gemtext parser in assembly, I'd be like, 'yeah sure why not.' If you asked me to write a parser for a *subset* of HTML in assembly, I'd tell you it wasn't possible. Like, okay, you'd have to say that you're not allowed to nest elements. (Because otherwise I have to come up with dynamic memory structures to store my theoretically infinite nested parse tree...) No attributes except for `href`, no elements except for `a`, `h1…6`, `pre`, `block quote`, wait! But if we have bulleted lists, then we have to nest elements. That's awful.
Like, imagine you have a feature-set, say, the stuff gemtext supports. And you want to be able to store and parse those features. Option 1, is all of the complexity of parsing HTML. Option 2 is literally designed to be as simple as possible to parse while support the needed features.
I haven't even gotten to servers. Chrome sends so fricking many headers, you'd need a dynamic memory system in order to handle an arbitrary number of headers. Modern browser could add more headers at any time. Firefox just invented the DNT header and started sending it. There's no way around the complexity and extensibility of the web.
Gemini is designed for non-extensibility. So you can write a server in assembly and allocate 1024 bytes for the URL and know that you'll never need more than that. Fun weekend project, Gemini server in assembly. It would be better than Astronomical Theater.