I understand why they didn't allow inline images, but I agree with you it limits a lot of use cases.

If I were designing it, I would say: "you can have images, but they always display as a 'block element', with nothing to either side. No worries about wrapping text; no background images under other elements, etc." I think that keeps the spirit of simplicity.

you can have images and they don't always display as anything. the author of the user agent decides how they are displayed. you could in-line them if you wanted to, but only a few clients do that at the moment. there are no hints to the client about how some content could, should, or should "always display as".

It's text. The client displays that text and renders links, headings, etc, however it wishes. If it really wants to, it could just not format them at all. There's a gemini client made for plan9's acme text editor that doesn't render links, and instead displays them verbatim, because the plan9 plumber can handle the hyperlinking aspect. All of that is eye candy and fluff.

If a client finds a link to an image, it can in-line it if it wants. If you wrote a client, when it found a link to an image, it would in-line it "with nothing to either side." That's not something that has to be specced.

You could have a setting on the client that lets the user specify that that's how they always want to see images, I on the other hand might specify that I want to open them in a new window, or see a thumbnail until i hover over, etc.

Same with how headers are displayed (maybe i want folding or something), whether an ToC is displayed, colours, fonts, etc.

The point is that the user can decide all this stuff, without having to hack it around the author's own styles and scripts.

> just like you expect in a newspaper etc.

Technical paper is what I was thinking about there. Furthermore, since Gemini apparently lacks support for mathematical notation images would be necessary for such even if the paper doesn't intrinsically contain non-textual images (e.g. pictures, charts, or graphs, which are common though not universal).

I'm not sure how recipes, for example, would be an issue without inline images. You click (or otherwise trigger) the image link and look at the image (potentially in a new tab or window) then go back to reading content. It isnt hard or even a bad experience. It is just different than current expectations based on comparing something that isnt the web to the web.

Being able to look at the image of the preparation step while reading the instructions is nice when making a recipe. Having to go to a separate page is annoying.

I agree, but I see this as a client-concern. I could imagine clients fetching and inlining images if the user directed it to, or maybe media-focused clients having a text pane alongside a media pane where the images would be rendered. The main advantage I see of this approach is that it takes us from "the server decides what the client does" to "the client decides what the client does".

Ok, but the recipe maker is going to want to suggest where to put the images (so they are in the proper spot on the recipe).... at which point, how is that different than html? A client can decide not to render the image where it is suggested already.

So did I. But I'm not going to let one drawback distract me from something otherwise very good, nothing is perfect after all.

I can even understand why they did it. To keep the doc format very simple.

I hope that more clients will add unique rendering features that will turn this drawback on it's head. It could be in-line rendering or a gallery-like feature.