5 ms·
> Blogs, [..] are perfect for the Gemini format. > Gemini lacks in-line images This is the only part that I don't really understand about Gemini. Even the mo
by avian 6y ago
> Blogs, [..] are perfect for the Gemini format.
> 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.
- mrob 6y agoNo technical limitation is suitable. The appropriate number or size of images depends on the accompanying text. Setting it high enough to allow all legitimate uses makes it weak enough that you might as well have no limit. And even a low limit does nothing to prevent annoying use up to that limit. The best possible limit is "must convince the reader to click it".
- avian 6y agoI guess that's a reasonable position to take. It reminds me of paper publications where you have all the figures on color plates bound in the middle/end, so I guess it isn't without precedent 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).
- vertex-four 6y agoBinary attachments were somewhat fiddly in Usenet, AIUI? I don't think MIME/8-bit clean support was really consistently there at the time. In Gemini, you'd just serve it as a binary file.
- rapnie 6y agoThere are a number of text-based diagram formats that could be supported, like PlantUml and such.
- fock 6y agoalso not really sure, how a protocol wants to be simpler than http (send bytes to port 80, get bytes, print bytes...) if it has baked in content limitations...
- 86J8oyZv 6y agoWhat about "inline images can't be linkable?" Caption text could still link to an enlarged/detailed version. But if images can never be clicked/linked, it would be hard to abuse them for ads the way we see today.
- warkdarrior 6y agoThat is adorably naive. This is why we have interstitials. (see https://en.wikipedia.org/wiki/Interstitial_webpage https://en.wikipedia.org/wiki/Interstitial_webpage )
- amelius 6y agoI think a better way to deal with advertisement images is with AI and/or collaborative filtering. If we can have spam filters for email, we can have ad filters for images.
- synctext 6y ago> Even the most basic printed publications can include illustrations. Streaming video is probably here to stay. /s
- daffy 6y agoCouldn't documents that require pictures just be downloadable PDFs?
- dragonwriter 6y agoI suspect, were gemini format to catch on, user agents would likely get an option to render images from links inline (either instead of links or as thumbnail previews attached to the links.)
- SilasX 6y agoJust as would happen with everything else about the modern web that the author objects to. That’s how we got into this mess in the first place. Related: why can’t we just point the blind at a protocol optimized for just sharing text documents? https://news.ycombinator.com/item?id=20225291 https://news.ycombinator.com/item?id=20225291
- zenojevski 6y agoThe ability for clients to render the markup as they please is actually one of the most important features, and a stark distinction from HTML, which only has one correct way to render. 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 https://i.imgur.com/dw3e4Ou.png And there are many more creative things that can be done with this. [0]: https://github.com/zenoamaro/unnamed-gopher-client https://github.com/zenoamaro/unnamed-gopher-client
- nicbou 6y ago> which only has one correct way to render 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.
- 8organicbits 6y agoTrue, but at a given resolution, with CSS turned on, and in dark mode all users will basically see the same HTML view. The user can't have a dark mode HTML page unless the web site offers one or the user has an extension that makes a best effort to create one. HTML with complex Javascript rendering makes it hard to give the user control. 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...)
- empath75 6y agoI was writing a client for Gemini and added a toggle to display images inline.
- sloum 6y agoThe 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 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).
- zokier 6y agoIf images are inlined in the document, then you can maintain that one request correspondence.
- lal 6y agoi 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.
- troupe 6y ago> 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.
- Terretta 6y agoImages are generally not the point. Formulas, diagrams and illustrations are. 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-enhanced https://github.com/shd101wyy/vscode-markdown-preview-enhance...
- samaxe 6y agoJust use ASCII art instead! It’s cooler anyway.
- naasking 6y agoThe reason to avoid linked images that are displayed inline in the page is because they would permit tracking. If you mean something like Base64 encoded inline images, then those might be viable.
- yoz-y 6y agoOr only allow content from the first party server?