|
I respect your disagreement, but I feel like you're disagreeing against the wrong point here though. The main difference between gemini (the protocol) and http, isn't that a gemini page need only contain text and be deprived of all other kinds of context. The gemini protocol does not stop you from interacting with specific filetypes or other protocols, any more than http does. It's a protocol. It's up to people implementing clients to the gemini protocol to decide how to handle such externalities. E.g. the lagrange browser downloads images and displays then inline in the page, which I like. I haven't tried audio files, but I imagine they could probably work similarly if necessary. Along similar lines, the gemtext specification is not intended as some sort of viable html alternative. It has completely different design goals. So no, the point isn't about limiting the kind of content you can interact with. The point is, by enforcing a degree of separation between what is "content" (i.e. text), and what is "externalities", this makes simplicity of text (both in terms of presentation and production) the main driver, leaving externalities up to implementations (which may be as simple as encouraging actual external use, including an http browser for http content). More importantly, this allows the user to be in control over how these potentially abusable externalities should be handled, rather than ceding that control to the webmaster, whose agenda may not match yours as a user. And some (including myself) actually like this separation. |
That's true, but it's based on opportunistic guesses, not semantics, which prevents many use-cases (including alt-text for accessibility of images). For example, we could do the same with video, but what about alternative soundtracks/captions? HTML has <video> <audio> and <caption>. Building a browser based on auto-guessing which link is related to which one and what the relationship is between those is... hazardous in my view.
> this allows the user to be in control over how these potentially abusable externalities should be handled, rather than ceding that control to the webmaster
I love that argument! But that was also the premise for the web, and i don't understand why we're not enforcing it there. CSS was supposed to permit user stylesheets, and JS empower users to script their interactions with the server. I would argue the problem with the web is it has moved away from declarative to imperative model where the server dictates your rendering. I can see how gemini addresses this by removing extensible declarative elements altogether, but i don't think that's the only way.
Personally, i think adding more semantic elements in HTML (eg. no-JS web components) would make client-side sheets more realistic while allowing the webmaster to propose a specific stylesheet for their recommended UI/UX. Removing the semantics is not gonna help empower clients, except when it comes to plaintext content. So, adding a new content-type over HTTP? Sure. Just throw in some CommonMark: it's well-specified and more or less complete (depending on your use-case). Adding a simpler protocol for delivering content? Why not, but it's not that easy to future-proof: HTTP is arguably more complex, but has some interesting properties such as content-type/encoding negociation or decoupling from transport security (for .onion/.i2p/DANE or any other future technology).
Just to be clear i like gemini very much and i've been wanting to support gemlog to my blog for a while. I just think there's room for some other technical foundations to explore the political promises of gemini.