The best possible limit is "must convince the reader to click it".
On the other hand, it made me think of old Usenet posts and discussions. That was another medium where you were limited to plain-text only. Posts were often forced to resort to awful ASCII-art drawings of things they wanted to explain and that was just a horrible experience altogether (not to mention how fun those drawings are to decipher today where modern archives have mostly messed up the white space).
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).
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.
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.
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"
I exploit this in my Unnamed Gopher Client[0], a client for the predecessor of the Gemini protocol, where I render links in a familiar files/folder format:
https://i.imgur.com/dw3e4Ou.png
And there are many more creative things that can be done with this.
A website can be rendered at different resolutions, with or without stylesheets, in dark mode, in printer-friendly formats, in a text-like format, with user stylesheets, with some elements hidden, as plain text, etc.
The concept of a user agent that gives the user much greater ability to choose how they want to view content could mean each user will:
* Pick their own font, font size, line spacing, margins
* Pick their own text color and background color. Like dark mode, high contrast, etc.
* Choose how linked images are shown: inline, click to load, load in new window, expandable thumbnails, etc
* How sections, section headers are displayed. Add a table of contents? Add a button to jump to the next section? The user can choose.
I like reader view, which gives me the ability to choose how I view HTML, but only when reader view can figure out how to extract the content (sometimes disastrously missing paragraphs of text...)
This thread is the first I've heard, and up until this comment I was thinking in my head, "sheesh, what kind of value proposition would justify that amount of work. I'm just not seeing it."
It's kind of like what REST was meant to be. More about entities than verbs. Cool. I get it now.
However, in my experience, the DOM for some sites is such a mess that trying to apply user preferences is a hack. I.E. reader view accidentally loses text. Does the implementation Opera has always work? That would be cool, although I'd still avoid Opera for privacy reasons.
Gemini seems to be to throw away all that complexity, which makes user customization easier. I.E. the problem is HTML/JS/DOM complexity, not a browser or its extensions.
1. https://www.ilovefreesoftware.com/29/featured/free-website-f...
Related: why can’t we just point the blind at a protocol optimized for just sharing text documents?
Managing image assets is tedious. The web design community still by and large hasn’t figured out a great standard way to do for images (versions with reversible/cherry-pickable diffs) what git does for code.
Instead, diagrams and formulas could follow the lovely ideas of mermaid, graphviz, dot, and mathjax inlined into the markdown as text. Tooling for VSCode handles inline diagrams beautifully for Markdown already.[1]
And then, inline SVG would let you illustrate nearly anything.
WSJ got by fine without photos, as did most journals for most of my lifetime, and Kindle books mostly don’t have them today. I wouldn’t be too quick to say a medium has to be filled with photos.
1. https://github.com/shd101wyy/vscode-markdown-preview-enhance...
If you mean something like Base64 encoded inline images, then those might be viable.
> Gemini lacks in-line images
This is the only part that I don't really understand about Gemini. Even the most basic printed publications can include illustrations. <img> got added to HTML very early on because sometimes it's hard to share some piece of information in anything but a visual form.
I write a (mostly) technical blog that certainly focuses more on text content than images. I would be happy to throw away the header, sidebar and the rest of the "design" cruft (in fact my blog is perfectly usable in a browser that doesn't support CSS or Javascript) But I can't imagine having my posts without graphs, diagrams and photos inserted in the text.
If the fear is that in-line images would lead to frivolous use as ads or "useless multi-megabyte header images", then maybe a better approach would be to limit the number, or size, of images on each page? Some scientific publications do exactly that in an attempt to force the authors to focus on selecting only the most important images that need to accompany their papers.