Hacker News Reader

Comment by sloum | Hacker News Reader

The lack of inline links is less about aesthetics and more about predictability. When you request a gemini resource you know that there will be two things happening: a TLS handshake followed by, hopefully, the server response (hopefully with your requested document).

Adding images requires more requests and breaks the concept of "one url/document == one request". I love that I know that my client will do nothing I do not tell it to do.

If you want to use gemini and you want inline images I believe https://proxy.vulpes.one does inline images of some form or other.

That said, images have other issues beyond causing page loads/requests to be unpredictable: they are an accessibility nightmare (as we have seen on the web).

View on HN

> they are an accessibility nightmare (as we have seen on the web).

Audio is an accessibility nightmare for people who can't see, text is an accessibility nightmare for people who can't see or people who can't read, German is an accessibility nightmare for people who can't speak German.

At some point we have to accept that not every way something is presented is going to be equally accessible by every person, but the solution isn't to just decide we should jettison a rich form of communication because there is a small subset that can't fully benefit from it. Even books that are expected to be used by people who can see all the images usually describe the purpose of the image, what it is illustrating, and why it was included.

> I love that I know that my client will do nothing I do not tell it to do.

By this line of reasoning, you would have to manually approve every init process that your computer would want to start every time you boot it up.

"images" == "client doing things I don't tell it to do" is completely false. Clients have been built that have configurable policies for loading images and scripts, and they're conceptually very simple and easy to use - e.g. "don't load images by default, click to load temporarily, control-click to load and permanently whitelist" is an example of a user-agent policy that not only supports images, but conforms to your extremely convoluted definition of a user-agent "do[ing] nothing I do not tell it to do."

> requires more requests

Is the purpose of a document browser to minimize requests, or to actually serve useful information? Images can encode data that cannot be encoded in text, and a vast quantity of information is much more easily read and understood in graphical form. If you want to minimize requests, then just don't use the web at all.

Also, this isn't even necessarily the case. You could encode images as part of the page, as base64 or something.

> they are an accessibility nightmare (as we have seen on the web)

The web supports alt-text for images. When people don't provide alt-text, that's not a technical problem, that's a social one.

> requires more requests

This is solved by HTTP/2 multiplexing https://en.wikipedia.org/wiki/HTTP/2

> breaks the concept of "one url/document == one request"

I don't think anyone cares about this "concept"

How’s about serving gzipped bundles of files? Just request that and get all your text and enriched content in one go

What prevents the Gemini client from adding a "click to display inline" button next to the image link?

This problem is easily solved by just not loading images by default but on-demand.

If images are inlined in the document, then you can maintain that one request correspondence.

i don't know if you understand what you're saying?? are you suggesting the binary content of a png file be inserted into the text-readable markup for a document? this doesn't make any sense. in-line images are linking to other resources. nobody just copy-pastes the hex content of an image into their website's html, because it will end up being 95% of the file size and a nightmare to look at in your editor.

Reply on news.ycombinator.com