💾 Archived View for tanelorn.city › ~bouncepaw › gemlog › html-over.gemini captured on 2020-11-07 at 02:11:30. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

HTML over Gemini

Posted at 2020-09-12

According to the Spec, gemini can serve any markup language, not just gemtext. I think it has been reminded about in that mailing list discussion under the subject ‘A proposed scheme for parsing preformatted alt text’. Perhaps it hasn't been. I'm not sure. I don't want to reread those 50 or so msgs.

Indeed, why extend gemtext when you can just use a markup language that has more capabilites? Yet still some folks try to extend gemtext.

I do, for example

While I think that gemtext should not be extended (despite me doing otherwise), I find the argument about serving different markup languages sort of weak.

To begin with, what markups can be served? HTML comes to mind first, and for a good reason; it is the HyperText Markup Language used in the World Wide Web! Everyone knows it (some people don't like it though). Moreover, it is the most semantic markup out there for now (at least I don't know any other semantic markups). I absolutely love wrapping articles in <article> and headers in <header>.

But it's not lightweight!

Yes, it is not. Let's look at what lightweight markups we've got.

Markdown sucks. There's a gemlog post in this link. I'm kinda opposed to the idea of using Markdown in gemini. It's so mainstream, so hipster, so dirty!

There's also Creole. I really like it, but its capabilities are laughable. Sure, it's more than gemtext but still a lot less than any dialect of Markdown. Every practical implementation of Creole would want to add more features. I'm planning to extend it so much in my wiki engine that I'd have to give it a different name.

There are also Rest, Asciidoc, Mediawiki markup, etc. Every markup has its own pros and cons which may turn away or to using that language for gemini content.

So should clients support all these markups? If they do, that'll be exactly the feature creep we're all so scared of for some reason. If they support only some markups while not supporting the others, we'll have so much trouble browsing the NQ2. If they support none, what's the point?

But what if we had a universal markup that all other markups can be converted into first before publishing? Oh, this is HTML. We're back here.

But it's hard to implement!

Yeah, it is. Look up for HTML5.2 spec. It's huge! Creating an AST for HTML5 is a lot harder than you may expect. For example, this is a valid markup:

<ul>
	<li>List element 1.
	<li>List element 2. Yeah, the previous one wasn't closed. So what? Parse it.
</ul>
Then why not fall back to HTML4?

HTML4 is a bad candidate for a universal markup. Under-specified, lacking many semantic tags, that's not what you want.

Then why not choose a subset of HTML5?

Yeah, let's drop <div> and <span> for greater good. These tags bear no semantic meaning and therefore shall be banished.

But it's still hard to render!

I think it's quite doable if you don't take CSS and DOM API into account. Actually, some clients do support HTML!

I have copied my website home page to this gemini page. Check out how it is rendered in your client of choice!

The original page is here, if you're interested.

I tested it in kristall (rendered quite good, but no image, only notice about its presence), portal.mozz.us (the same, but the image is dropped silently), castor (source code shown) and amfora (source code shown). So, some clients support HTML but how good do they do it? I think that not good enough.

I hope this short article has given you some thoughts on the topic. To summarize, here're my points: