undefined | Better HN

0 pointssoutherntofu4y ago0 comments

> Gemini does not prevent you from having any of those things.

I strongly disagree. By willingly limiting the markup, gemini actively tries to prevent you from doing these things. In contrast, what's wrong with the web is everything JavaScript and some early design issues with CSS, but HTML is good (although it could be simplified/improved).

xHTML more specifically is easy to parse and extensible so that different clients can implement more features. We need more HTML less JavaScript. In this sense, going the gopher route is a step backwards in my view, because it means for most of my practical needs (such as a simple user-submitted form) i need to stick with the web as we know it while i would be more than happy to take part and contribute in a privacy-friendly/minimalist subset of the web (as a standard i mean, i already do that on my websites).

0 comments

tpoacher4y ago

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.

southerntofuOP4y ago

> E.g. the lagrange browser downloads images and displays then inline in the page

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.

j / k navigate · click thread line to collapse