There are no inline links (every link goes on its own line), no formatting, and no inline images
So it’s borderline useless for all but the simplest use cases, and even there it does a very subpar job. I’d like to have an inline image every now and then, or organize things in some multi-column layouts or the like, or a table. 19th century newspapers could do this, and if your technology can’t emulate typography produced on a daily basis – often in a hurry – 150 years ago then your tech is rather limited.
These protocols keep shooting themselves in the head with stuff like this, not even in the foot because this entire thing is dead on arrival for all but a few niche tech folk.
I see this a lot, and I really, really wish that the people making this case would actually try to use Gemini for what it is before bringing their preconceptions into it. Easily a full third of the people I’ve spoken to about Gemini immediately start talking about some $FEATURE that they would add to it - and I’ve heard a lot of different features. Do you see the problem with this? This is just a recipe for re-inventing the bloat of the web.
You must first use, then understand, then change the software. You can’t skip steps one and two. It is possible to express yourself within these constraints (you’re already expressing yourself within some fairly arbitrary constraints right now, for instance, imposed by Lobsters’ strict markdown rules), and you should first apply a little bit of creativity to the new medium before you try to bend the medium to your will. We don’t really want it bent, we’re doing something different for a reason.
By the way, your comment can be losslessly represented in Gemtext.
Easily a full third of the people I’ve spoken to about Gemini immediately start talking about some $FEATURE that they would add to it - and I’ve heard a lot of different features. Do you see the problem with this? This is just a recipe for re-inventing the bloat of the web.
I’d argue that this is because the problems it solves are inherently complex, so any good solution to it will be complex as well. That doesn’t mean I don’t think the web can’t be improved or made simpler – it’s an organically grown mess of 25 years – but it will never be replaced by a dead-simple solution such as Gemini.
And yeah, my Lobsters comments can be expressed in Gemini without much loss (except the inline links thing), but Lobsters isn’t my website though and I wouldn’t be able to express my fairly simple website on Gemini, or a fairly simple site as Wikipedia. And even the entire Lobsters website would be a worse UX in Gemini as it precludes any sort of design.
But isn’t this very limiting? Like, it would work for your blog, but in its current iteration adding a table would already be difficult, never mind something more advanced like the fivethirtyeight election forecast and results.
I suppose it all depends what your vision for Gemini is; if you want it to replace large parts of the web then it’s got basically 0 chance in its current state; if you just want some alternative to use yourself and like-minded people, then sure, go for it.
Of course Gemini doesn’t preclude design: It’s a networking protocol. You can use it to move HTML and JS and CSS and images and whatever else just fine.
Attempting to conflate a protocol with a document format is wrong.
The specification also includes a document format, as well as a networking protocol.
Arguably, things would have been clearer if they were separated out more clearly, but this would kind of defeat the point of Gemini. The networking protocol and document format are intended to be used together.
It seems interesting; to make it clear, I do hate tracking too, as well as inaccessibility & various Flash-equivalents of today. And dependency on the complexity tower of Chrome/Firefox/… So I’m certainly curious about alternatives to the current status quo.
I do understand that the protocol seems to allow for a lot of expression, and more “slow-food” style, relaxed consumption. Yet, I cannot escape immediately having a feeling of loss. If I understand this correctly, with no mathematical equations support, I would not be able to write or consume an article trying to explain Shor’s algorithm. With no graphs support, I assume whenever I’d want to display graphs, I’d have to resort to ASCII-Art as a workaround, with necessarily limited precision (for example, no smooth curves or complex 3D surfaces). Finally, I assume I would not be able to write or consume an article about typography, or bysantine icons. Or am I wrong?
Having the concerns mentioned above, I’m immediately starting to think about possible workarounds. I am assuming people would start resorting to “rich clients” - for example, with support for rendering of some kinds of mathematical equations. This, I am guessing, would quickly lead to on-site recommendations like: “This page requires support for LaTeX-Super-Renderer-3.7”. De-facto becoming in-band signaling of the kind Gemini apparently tries to dispell by “only allowing one field in response, the mimetype”. But wouldn’t people start doing that anyway, and start writing such plugins anyway, and start de-facto reinventing HTML anyway? With the likes of Flash plugins of yore raising from the dead in new clothes?
With regards to just graphs and images, I believe it could be somewhat easier actually. I am now reminded of the days of my childhood, when books in my country were mostly in black and white, with a few pages in the center being in color, and being referenced to by the b&w pages (“See illustration 7.b.”). I imagine something like that could work with images being listed, or linked, or attached (?) at the end of a Gemini page. But even then, I don’t think that would be usable for math-heavy documents. And from glancing through the few links around here, it’s not fully clear to me if any images at all, even at the end of a document, are expected to be supported? (Though mimetypes support kinda seems to hint at allowing this?)
So, with the ideal of simplicity sounding theoretically interesting and alluring, at the same time I’m concerned about losing access to, especially, maths-related content. (Assuming that some image-heavy, yet comparatively sparse in that regard, content could be possibly approximated with a list of image links at the end, referenced from the main article. Which kinda already sounds like a hack, that would probably soon lead to reintroducing inline images via specialized clients…) That feels like a pity to me.
I do understand that the protocol seems to allow for a lot of expression, and more “slow-food” style, relaxed consumption. Yet, I cannot escape immediately having a feeling of loss. If I understand this correctly, with no mathematical equations support, I would not be able to write or consume an article trying to explain Shor’s algorithm. With no graphs support, I assume whenever I’d want to display graphs, I’d have to resort to ASCII-Art as a workaround, with necessarily limited precision (for example, no smooth curves or complex 3D surfaces). Finally, I assume I would not be able to write or consume an article about typography, or bysantine icons. Or am I wrong?
I’ve brought this issue about math up in the past, but remember, nothing is stopping you from using HTML or PDF. Gemini uses Gemtext as a lowest-common-denominator form of markup, but if you are writing a client, you can always built in HTML support or shell out to something else that does.
I think that the reason that people keep trying to suggest features is that Gemini is marketed as a replacement for “the web”, but designed (and only useful) as just a plain text delivery mechanism - there’s (rightly) some cognitive dissonance going on.
That is, “the web” includes plain text, hypertext, rich documents, audio/video media, and interactive content. I don’t think that most people expect Gemini to implement the last two, but there’s some reasonable expectation that something trying to replace “the web” should at least be able to represent reasonably interesting documents - such as scientific papers, which Gemini clearly cannot.
Perhaps if proponents of Gemini stopped trying to claim that it could actually replace anything but the tiniest slice of the web that is pure, plain text (not hypertext, as inline links are really important), you would stop getting people talking about adding features.
Edit: that is, there’s no “preconception” going on here. GP post is responding to the argument that Gemini is a viable replacement for the web by pointing out that it is missing critical features for actually acting as a sane replacement, which has no “preconception” - it’s just a statement of fact. You cannot replace the web without inline links, formatting, or inline images, full stop.
None of these sites, or the majority of the thousands of other bookmarks that I have, can be replaced without inline links, formatting, or images.
Linked files do. Not. Cut. It.
Not only are linked (vs. inline) files objectively and meaningfully different (and, therefore, you cannot replace the web with them), but they are inferior from an information-processing standpoint. From both a practical and theoretical level, you cannot replace the web with Gemini as it currently stands. People will not use it, they are not equivalent, and I, personally, will discourage people from using it - it is a cognitive anti-tool, similar to a reverse printing press. Useful for implementors, terrible for anyone who actually wants to read documents and exchange information that will actually help them to learn and reason.
I can provide another counter-example: you had 5 links in your comment, none of which were inlined, despite having access to inline links on lobsters.
You can’t place identical content on Gemini as you can on the web. You can reformat your content for the new medium. Nothing transitions between mediums without change.
Gemini replaces a subset of the web, which I stated in the opening article and have re-iterated dozens of times.
I can provide another counter-example: you had 5 links in your comment, none of which were inlined, despite having access to inline links on lobsters.
…that’s not a counter-example. I never claimed that you can’t replace any of the content on the internet, which is what that statement would be a counter-example to. Perhaps you should take a logic course. Edit: that was too aggressive, my apologies.
Edit: I claimed that you cannot replace “the web”, which implies replacing the majority of the content at least, and all of the content at most.
You can’t place identical content on Gemini as you can on the web. You can reformat your content for the new medium.
…and, as it should be very clear, that re-formatting process is (1) lossy and (2) causes a significant decrease in readability and information processing - meaning that it is not a replacement. The format of the web is part of the web, therefore you cannot replace the web with Gemini.
Gemini replaces a subset of the web, which I stated in the opening article and have re-iterated dozens of times.
You have tried to claim that Gemini can replace anything but the tiniest trivial slice of the web that is pure, un-hyperlinked plain-text - which, as shown above, is false. The format of the web is part of the web. The content and the medium are entwined.
Anything with “less features” is lossy, but that’s not correlated with a “significant decrease in readability”. On the other hand, putting the presentation entirely into the client’s control is a significant win for readability, because the user can configure fonts, contrast, and layout to their preferences and usability needs. The screen reader experience, for instance, is WAY better. Inline links and inline formatting are less accessible to some.
Only true in the most needlessly pedantic sense. You can easily build systems with a small set of carefully-chosen features that still implement the vast majority of the functionality of larger systems that were poorly-built. This…does not describe Gemini. Gemini picked a basis of features that do not allow it to implement more complex functionality or richer documents.
that’s not correlated with a “significant decrease in readability”
Not in general, sure - but in the case of Gemini, it’s pretty clear that there is a significant decrease in readability (and, therefore, cognitive processing ability). Requiring users to click through to a separate document for each image, animation, or individual mathematical equation is extremely unreadable for anything with a reasonable density of those things - while “only” being merely slightly less readable for documents with only a few of those objects.
On the other hand, putting the presentation entirely into the client’s control is a significant win for readability
the user can configure fonts, contrast, and layout to their preferences and usability needs
You can already almost entirely control presentation with major browsers for the current web, through userscripts and stylesheets.
Moreover, HTML is actually structured, unlike Gemtext, so I have anchor points and document metadata that I can use to exert more control over my content than with unstructured Gemtext - so your statement is actually untrue.
The screen reader experience, for instance, is WAY better.
Modern web gives you more options to make a good screen reader experience - such as image alt text. Is it really inconsistently used? Sure, but that’s not a technical problem, that’s a social one - a social one that manifests itself in an equally bad way with Gemini, because Gemtext doesn’t have any way to bind accessibility-related metadata to document structure, because there is no document structure.
Inline links and inline formatting are less accessible to some.
Expanding links and controlling inline formatting are very basic features for screen readers.
So, to summarize, modern web gives you a much richer interface for screen readers, as well as a better interface for people who don’t use screen readers (which is the majority).
Gemtext is straight-up less conducive to thought and information transfer.
I think “significant decrease in readability” is interpreted a little too literally here.
Many of the documents linked by fouric would be way more inconvenient to read if they were adapted to fit in gemini’s limitations because of how heavily they rely on tables, anchor links to a specific part of the same document, and inline images (especially with how inconsistent most clients available today are at dealing with non-gemtext content types).
I personally am a big fan of how gemtext files only ever result in a single request due to the lack of stylesheets, scripting, and inline resources, and have pushed back on the adoption of HTML and Markdown as alternate document content types because I think that is a valuable part of the protocol. I’m also not delusional: the stance I hold also directly limits the mass appeal of gemini as a technology, because normal people who just want to read these kinds of documents are unlikely to accept what seems like massive inconvenience for technical reasons they don’t fully understand. They’ll just stick to the Web.
I am willing to put up with that inconvenience as a reader and writer of gemtext content because I think the other benefits of gemini are worth it, but I don’t expect anyone who isn’t another disillusioned Web developer to get on board quite as easily.
By the way, your comment can be losslessly represented in Gemtext.
This isn’t quite true, is it? His comment included the clearly-delineated metadata of his name and the time, including an inline graphic element (his avatar) to aid the eye in scanning the page for it. Gemtext as currently defined precludes any such niceties because they are perceived as ornament by the early community (who ironically see a need for some headings, lists, quotes, and … ASCII art).
It also included a simple method for you to add a reply. POST is a slippery slope, but I hope Gemini someday gains a sort of Micropub.
(I am one of those $FEATURE users, where $FEATURE is inline images and metadata or some sort of “secondary” text. But I’ll finish building my capsule and client and see how things evolve.)
You just wouldn’t have lots of inline links. You’d have a separate list of references, perhaps. Here are some examples of Gemini posts I have written with lots of links:
Let me put it this way: how would inline links work in a newspaper, book, or magazine? The answer is: they wouldn’t, and you just work within those limitations. That doesn’t mean the medium is bad.
19th century newspapers could do this, and if your technology can’t emulate typography produced on a daily basis – often in a hurry – 150 years ago then your tech is rather limited.
Not arguing against you, but when it comes to web browsers, then they still haven’t learnt to properly hyphenate text. Another thing we could do 150 years ago. One of the reasons (another being rather poor support for rendering maths, or, in the case of Chromium, complete lack of it) I’m relieved whenever I get to read a PDF generated from LaTeX instead of a webpage.
If I use soft hyphens, then copying He­re are rhi­nos. to terminal results in He re are rhi nos. visually, because it copied the text with the soft hyphens even though everything was on a single line.
LaTeX certainly requires some manual help.
It never required it when I used it. When you enable correct language support, it should just work.
I thought this analogy was cute for a little bit. But seriously, why is 150 years ago the standard? Are we really that painfully nostalgia-blind that we can’t recognize there’s a medium point between the old and the new?
It isn’t my standard, and frankly I don’t really care what we could / couldn’t do 150 years ago because I don’t believe it matters in the context of what are we doing, trying to do, and can’t do today.
Well, 150 years ago it was a manual process, and not an automatic one :-) I regularly insert ­ for this on my website by the way. But yeah, I agree that the lack of a universally supported hyphenate: auto has been long overdue (only Firefox supports it, and it doesn’t even do a great job at it, although I don’t know if there are technical reasons that prevent it from doing a better job; I think I saw someone on HN detail some issues with automatic hyphenation on the web years ago, but I forgot what they were).
Math rendering has also been supported by Firefox for 15 years with MathML, but for some reason Chrome doesn’t (but Safari does). Actually, looks like they removed it in Chrome years ago, although it looks like there’s work to add it back soon-ish.
Actually, along with Firefox, some versions of Chrome (Android & Mac) support auto hyphenation, and Safari has it hidden behind a prefix: https://caniuse.com/css-hyphens I feel that together these may cover enough of the market to make it worth adding to web pages.
If you want to see a quick and stupid demo, here’s my very unfinished Hugo theme I’m working on developing: https://www.maximumethics.dev/blog/2020/07/my-first-post/ If you shrink the viewport width until it’s skinny like a phone, you’ll see the longer 90 chars “alphabet” line break to hyphenate (on the aforementioned supported browsers), as well as random words in the text.
Ah yeah, it’s just the desktop version that doesn’t support it for some weird reason; I forgot about that detail.
I suppose it depends what you use it for: most of the time I really wanted auto hyphenation is for comparatively narrow pieces of text and/or for text-align: justify (e.g. a sidebar or info box). In those cases the hyphenation (manual or automatic) is pretty much a must-have rather than a nice-to-have, because without it it just looks ugly. Your site, on the other hand, looks fairly decent without hyphenation even on smaller screens, but it won’t hurt to add it for browsers that support it.
Math rendering has also been supported by Firefox for 15 years with MathML, but for some reason Chrome doesn’t (but Safari does). Actually, looks like they removed it in Chrome years ago, although it looks like there’s work to add it back soon-ish.
That’s what I was on about. If something isn’t available in Chrome, it’s irrelevant these days. I’ve been aware that “it looks like there’s work to add it back soon-ish” for quite some time now. I don’t have hope.
I think the idea is that the publisher delivers only the information, not the presentation. This constraint allows for greater user control over presentation, for example one might configure Gemini to lay out news articles (maybe on a site by site basis) in a column style, to suit their preferences. I think it’s an interesting idea as a way of making better typesetting more widely available to content published on sites without the budget / know-how to tune their CSS for readability.
I agree that Gemini would be better off if it supported inline images. That’s pretty often part of the information layer.
Not really, HTML still focuses a lot on presentation. Headers, side bars, footers, nagivation line, footnotes, etc. are all concepts foreign to the browser, that have to be manually re-implemented in the markup language, again and again. That’s actually what I think that protocols like Gemini misunderstand: HTTP/HTML is not too systamatically complicated (at most it’s “organically” complicated), it’s actually too simple. If for example the <head> section had made it possible to describe how a web-page is navigated, it would have been possible for the browser to render that part of the site, leaving the <body> to be actual content. It’s something you see with other simple languages too: Scheme has various implementations, that implement a common core, but diverge in their additional libraries, that are regarded as useful, but do not allow for code to be portable. So too, had HTTP/HTML has the foresight to recognize what people would want from websites (which is probably too much to ask), or at least the foresight to allow a certain degree of extensibility, a lot of implementation-specific complexity could have probably been avoided.
So the issue might not be “simplicity vs compexity”, but “what kind of complexity”.
Years ago I came across a browser extension that would build a navigation bar if it found certain <link> tags in the header. I modified my blogging engine to automatically add said links. Sadly, the extension no longer runs (because of course the extension mechanism changed—at least twice—since then) but I still generate the data in the vain hope it’ll be useful again.
A strict separation of information and presentation is something that sounds great in theory, but doesn’t really work all that well in practice once you move beyond the simple use cases, or use cases that are pre-defined and supported in some way.
I don’t know if this was part of the design goal - from what I can see, Gemini doesn’t have any sort of mechanism to describe or annotate what content/information is being delivered, which would make any presentation strategy necessarily heuristic, as there would be no way to delineate e.g. where the “author” of the article is.
I’m not quite sure what you mean - when you say “just put that information into the document itself” do you mean in a machine-readable format? Because if so, that’s not part of the Gemini text spec - which is the thing being discussed. Adding tags like <address> would be extending the Gemini spec to add features, which is what proponents of it are fiercely against.
As it has been stated on the mailing list, “you can always serve up text/html or text/markdown, you aren’t limited to text/gemini.” There are sites out there serving up images and even music.
Well, that’s not really what’s advocated for in this post (or on the Gemini website as far as I could see), and serving HTML over Gemini just sounds like a s/HTTP/Gemini/, and you can serve text or Markdown over HTTP as well. I don’t really see the point if you’re going to serve HTML over Gemini.
I’m sick of how complex html+css+js gets, and how complicated extracting the actual content can be, in order to view it on “unusual” platforms (small screens. ereaders, etc.), where a good experience depends on the client controlling the presentation of the content. Something like gemini could be the solution to that, but I have to say, the lack of inline images is a deal-breaker for me.
I view multi-column layouts as part of the presentation, not the content (I don’t want two columns of text on a phone screen: if I do want two columns of text on the desktop, I can write that into the client), but the images are part of the content.
I did wonder whether technically a gemini-ish client could fetch urls which look like they point to images and display them inline, but this is explicitly banned by the specification:
Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. gemini://, gopher://, https://, ftp://, etc.).
I can sort of see what they’re aiming for, presumably trying to avoid the sort of nonsense some websites have become, where the initial request just gets a jumble of html elements that require the client to fetch and execute tons of javascript before they can be assembled into something resembling content, but I think they should have made an exception for images (They could still leave it up to the client whether it displays inline images or not).
Interestingly, gemini probably works really well with screen readers, until you get to an image link (or any link for that matter), at which point it depends entirely on whether the author bothered to provide a caption, or explain what the link is as part of the text (Although that’s arguably no worse than html, where the existence of alt text doesn’t mean that it is always used or used correctly).
One big reason I’m excited about Gemini is the possibility of escaping the web’s bloat, which we need to do in order to reduce energy usage / emissions in the climate crisis. For this reason, I support Gemini’s decision to ban inline images. If you have inline images, next people will want inline video, and soon even if Gemini is “simpler” it’s using as much storage+bandwidth+processing as a web page.
Inlining images, especially from other locations, is also a plausible method for sneaking user tracking back into the protocol, and I also approve of Gemini’s strong efforts towards privacy. I also hate ads even when they don’t track people, I’d love to live someplace where billboards are banned so I can escape the constant background hum of marketing. Eliminating inline images is also a great way to reduce the annoyance of advertising.
I’m going to have to agree with everyone in this thread that refusing to implement inline links was a mistake, though. That was one of the biggest problems I had with Gopher, and I was hoping Gemini would do a better job with hypertext.
Inlining images, especially from other locations, is also a plausible method for sneaking user tracking back into the protocol, and I also approve of Gemini’s strong efforts towards privacy.
It’s a very difficult balance to strike between simplicity and functionality. You could probably avoid trackers by, as @m_eiman says, only allowing additional requests from the same domain as the original document.
Alternatively, you could create/use a format which embeds the images directly in the original document (similar to how pdf or epub does). Some might argue that this is inefficient, as you need to serve multiple copies of the image data if it appears on multiple pages. However, in this context, it could be seen as a feature, as we don’t want the kind of images (such as ads) which aren’t actually “part of the document”.
There will always be some people who abuse any protocol, but not having inline images is very limiting and means it isn’t any good for a significant portion of (what I consider) “good content that doesn’t need javascript/css”.
But ASCII art is pretty much the quintessence of mixing presentation and content, which is very specifically what Gemini seeks to avoid. It can’t wrap or scroll differently on small devices, it can’t be extracted (easily and reliably) to a machine-readable data format, and it isn’t accessible because there’s no semantic information about the table structure.
I need to click a link to an image? It seems pretty obvious to me that this is worse UX than just displaying it.
ASCII art relies on a monospaced font, which I don’t really like for reading text. I think Lobsters would be significantly worse if it was all monospaced text for example. It also relies on a certain screen size, which doesn’t work for smaller screens (or very big ones, for that matter). I mean, it kinda works but it’s a hack.
I need to click a link to an image? It seems pretty obvious to me that this is worse UX than just displaying it.
Yeah. You’re completely right, this is worse UX. I’m beginning to think of proposing an inline-image syntax for the gemini spec.
ASCII art relies on a monospaced font, which I don’t really like for reading text.
I admit I was wrong. ASCII tables are a hack, I suppose. Hopefully the simple table syntax I’m thinking of right now makes it into the spec!
I think Lobsters would be significantly worse if it was all monospaced text for example. It also relies on a certain screen size, which doesn’t work for smaller screens (or very big ones, for that matter). I mean, it kinda works but it’s a hack.
FYI there are gemini clients that support variable-width fonts.
FYI there are gemini clients that support variable-width fonts.
I tried to use it with Gopher years ago (I hacked up an existing client), and many sites don’t really work all that well because they assume stuff will be displayed as monospaced text (such as tables you mentioned, but also things like code examples, or other alignment things).
Gemini is a bit of an improvement because the spec at least recognizes that proportional text exits and has “code blocks”, but it also leaves much to the clients. In other words: I wouldn’t be surprised if people would just keep using it as they used Gopher, and the weird (and IMO, broken) way line wrapping works in Gemini doesn’t help either. I suppose time will tell how it will be used in practice (but as mentioned, I don’t think it will be used much in practice beyond a few “Hacker blogs” like Drew’s).
One of the big mistakes of HTML was, ironically, to “leave it up to the clients” which resulted in a big mess which had to be unified so that people could get a reasonably consistent experience irregardless of which browser they use, but that just unified the mess instead of clearing it up.
Gemini is only a protocol, but the specification also propose a basic text/gemini format as a de-facto document type. It however supports any mimetype, including text/html:
5 The text/gemini media type
5.1 Overview
In the same sense that HTML is the “native” response format of HTTP and plain text is the native response format of gopher, Gemini defines its own native response format - though of course, thanks to the inclusion of a MIME type in the response header Gemini can be used to serve plain text, rich text, HTML, Markdown, LaTeX, etc.
You could totally sent the following HTML document over gemini:// and enjoy inline images:
It would then be up to the gemini client to process this document, fetch required resources (the cat picture) and render it nicely for you. The advantage of the gemini protocol here is that it would put a limit on the HTML subset one could put in a document. For example, <form> tags won’t be any useful. There would also be no need for <script> tags, as they wouldn’t be able to “phone home” over gemini.
One of the biggest problem of the web is that the HTTP protocol itself grew in an enormous monster that’s impossible to understand, where sometimes the headers of a requests can be 10 times bigger than the content itself.
So it’s borderline useless for all but the simplest use cases, and even there it does a very subpar job. I’d like to have an inline image every now and then, or organize things in some multi-column layouts or the like, or a table. 19th century newspapers could do this, and if your technology can’t emulate typography produced on a daily basis – often in a hurry – 150 years ago then your tech is rather limited.
These protocols keep shooting themselves in the head with stuff like this, not even in the foot because this entire thing is dead on arrival for all but a few niche tech folk.
I see this a lot, and I really, really wish that the people making this case would actually try to use Gemini for what it is before bringing their preconceptions into it. Easily a full third of the people I’ve spoken to about Gemini immediately start talking about some $FEATURE that they would add to it - and I’ve heard a lot of different features. Do you see the problem with this? This is just a recipe for re-inventing the bloat of the web.
You must first use, then understand, then change the software. You can’t skip steps one and two. It is possible to express yourself within these constraints (you’re already expressing yourself within some fairly arbitrary constraints right now, for instance, imposed by Lobsters’ strict markdown rules), and you should first apply a little bit of creativity to the new medium before you try to bend the medium to your will. We don’t really want it bent, we’re doing something different for a reason.
By the way, your comment can be losslessly represented in Gemtext.
I’d argue that this is because the problems it solves are inherently complex, so any good solution to it will be complex as well. That doesn’t mean I don’t think the web can’t be improved or made simpler – it’s an organically grown mess of 25 years – but it will never be replaced by a dead-simple solution such as Gemini.
And yeah, my Lobsters comments can be expressed in Gemini without much loss (except the inline links thing), but Lobsters isn’t my website though and I wouldn’t be able to express my fairly simple website on Gemini, or a fairly simple site as Wikipedia. And even the entire Lobsters website would be a worse UX in Gemini as it precludes any sort of design.
Gemini does not preclude any sort of design, not at all - it just gives the responsibility for design to the client, not to the server.
But isn’t this very limiting? Like, it would work for your blog, but in its current iteration adding a table would already be difficult, never mind something more advanced like the fivethirtyeight election forecast and results.
I suppose it all depends what your vision for Gemini is; if you want it to replace large parts of the web then it’s got basically 0 chance in its current state; if you just want some alternative to use yourself and like-minded people, then sure, go for it.
Of course Gemini doesn’t preclude design: It’s a networking protocol. You can use it to move HTML and JS and CSS and images and whatever else just fine.
Attempting to conflate a protocol with a document format is wrong.
The specification also includes a document format, as well as a networking protocol.
Arguably, things would have been clearer if they were separated out more clearly, but this would kind of defeat the point of Gemini. The networking protocol and document format are intended to be used together.
It seems interesting; to make it clear, I do hate tracking too, as well as inaccessibility & various Flash-equivalents of today. And dependency on the complexity tower of Chrome/Firefox/… So I’m certainly curious about alternatives to the current status quo.
I do understand that the protocol seems to allow for a lot of expression, and more “slow-food” style, relaxed consumption. Yet, I cannot escape immediately having a feeling of loss. If I understand this correctly, with no mathematical equations support, I would not be able to write or consume an article trying to explain Shor’s algorithm. With no graphs support, I assume whenever I’d want to display graphs, I’d have to resort to ASCII-Art as a workaround, with necessarily limited precision (for example, no smooth curves or complex 3D surfaces). Finally, I assume I would not be able to write or consume an article about typography, or bysantine icons. Or am I wrong?
Having the concerns mentioned above, I’m immediately starting to think about possible workarounds. I am assuming people would start resorting to “rich clients” - for example, with support for rendering of some kinds of mathematical equations. This, I am guessing, would quickly lead to on-site recommendations like: “This page requires support for LaTeX-Super-Renderer-3.7”. De-facto becoming in-band signaling of the kind Gemini apparently tries to dispell by “only allowing one field in response, the mimetype”. But wouldn’t people start doing that anyway, and start writing such plugins anyway, and start de-facto reinventing HTML anyway? With the likes of Flash plugins of yore raising from the dead in new clothes?
With regards to just graphs and images, I believe it could be somewhat easier actually. I am now reminded of the days of my childhood, when books in my country were mostly in black and white, with a few pages in the center being in color, and being referenced to by the b&w pages (“See illustration 7.b.”). I imagine something like that could work with images being listed, or linked, or attached (?) at the end of a Gemini page. But even then, I don’t think that would be usable for math-heavy documents. And from glancing through the few links around here, it’s not fully clear to me if any images at all, even at the end of a document, are expected to be supported? (Though mimetypes support kinda seems to hint at allowing this?)
So, with the ideal of simplicity sounding theoretically interesting and alluring, at the same time I’m concerned about losing access to, especially, maths-related content. (Assuming that some image-heavy, yet comparatively sparse in that regard, content could be possibly approximated with a list of image links at the end, referenced from the main article. Which kinda already sounds like a hack, that would probably soon lead to reintroducing inline images via specialized clients…) That feels like a pity to me.
I’ve brought this issue about math up in the past, but remember, nothing is stopping you from using HTML or PDF. Gemini uses Gemtext as a lowest-common-denominator form of markup, but if you are writing a client, you can always built in HTML support or shell out to something else that does.
I think that the reason that people keep trying to suggest features is that Gemini is marketed as a replacement for “the web”, but designed (and only useful) as just a plain text delivery mechanism - there’s (rightly) some cognitive dissonance going on.
That is, “the web” includes plain text, hypertext, rich documents, audio/video media, and interactive content. I don’t think that most people expect Gemini to implement the last two, but there’s some reasonable expectation that something trying to replace “the web” should at least be able to represent reasonably interesting documents - such as scientific papers, which Gemini clearly cannot.
Perhaps if proponents of Gemini stopped trying to claim that it could actually replace anything but the tiniest slice of the web that is pure, plain text (not hypertext, as inline links are really important), you would stop getting people talking about adding features.
Edit: that is, there’s no “preconception” going on here. GP post is responding to the argument that Gemini is a viable replacement for the web by pointing out that it is missing critical features for actually acting as a sane replacement, which has no “preconception” - it’s just a statement of fact. You cannot replace the web without inline links, formatting, or inline images, full stop.
As a matter of fact, you can. Full stop.
…that’s so obviously false that I shouldn’t need counterexamples, but here they are:
https://graphicallinearalgebra.net/2015/04/26/adding-part-1-and-mr-fibonacci/
http://foldr.org/mw/emacs/
http://507movements.com/
https://lobste.rs/
https://www.av8n.com/physics/clifford-intro.htm
None of these sites, or the majority of the thousands of other bookmarks that I have, can be replaced without inline links, formatting, or images.
Linked files do. Not. Cut. It.
Not only are linked (vs. inline) files objectively and meaningfully different (and, therefore, you cannot replace the web with them), but they are inferior from an information-processing standpoint. From both a practical and theoretical level, you cannot replace the web with Gemini as it currently stands. People will not use it, they are not equivalent, and I, personally, will discourage people from using it - it is a cognitive anti-tool, similar to a reverse printing press. Useful for implementors, terrible for anyone who actually wants to read documents and exchange information that will actually help them to learn and reason.
I can provide another counter-example: you had 5 links in your comment, none of which were inlined, despite having access to inline links on lobsters.
You can’t place identical content on Gemini as you can on the web. You can reformat your content for the new medium. Nothing transitions between mediums without change.
Gemini replaces a subset of the web, which I stated in the opening article and have re-iterated dozens of times.
…that’s not a counter-example. I never claimed that you can’t replace any of the content on the internet, which is what that statement would be a counter-example to.
Perhaps you should take a logic course.Edit: that was too aggressive, my apologies.Edit: I claimed that you cannot replace “the web”, which implies replacing the majority of the content at least, and all of the content at most.
…and, as it should be very clear, that re-formatting process is (1) lossy and (2) causes a significant decrease in readability and information processing - meaning that it is not a replacement. The format of the web is part of the web, therefore you cannot replace the web with Gemini.
You have tried to claim that Gemini can replace anything but the tiniest trivial slice of the web that is pure, un-hyperlinked plain-text - which, as shown above, is false. The format of the web is part of the web. The content and the medium are entwined.
Anything with “less features” is lossy, but that’s not correlated with a “significant decrease in readability”. On the other hand, putting the presentation entirely into the client’s control is a significant win for readability, because the user can configure fonts, contrast, and layout to their preferences and usability needs. The screen reader experience, for instance, is WAY better. Inline links and inline formatting are less accessible to some.
Only true in the most needlessly pedantic sense. You can easily build systems with a small set of carefully-chosen features that still implement the vast majority of the functionality of larger systems that were poorly-built. This…does not describe Gemini. Gemini picked a basis of features that do not allow it to implement more complex functionality or richer documents.
Not in general, sure - but in the case of Gemini, it’s pretty clear that there is a significant decrease in readability (and, therefore, cognitive processing ability). Requiring users to click through to a separate document for each image, animation, or individual mathematical equation is extremely unreadable for anything with a reasonable density of those things - while “only” being merely slightly less readable for documents with only a few of those objects.
You can already almost entirely control presentation with major browsers for the current web, through userscripts and stylesheets.
Moreover, HTML is actually structured, unlike Gemtext, so I have anchor points and document metadata that I can use to exert more control over my content than with unstructured Gemtext - so your statement is actually untrue.
Modern web gives you more options to make a good screen reader experience - such as image alt text. Is it really inconsistently used? Sure, but that’s not a technical problem, that’s a social one - a social one that manifests itself in an equally bad way with Gemini, because Gemtext doesn’t have any way to bind accessibility-related metadata to document structure, because there is no document structure.
Expanding links and controlling inline formatting are very basic features for screen readers.
So, to summarize, modern web gives you a much richer interface for screen readers, as well as a better interface for people who don’t use screen readers (which is the majority).
Gemtext is straight-up less conducive to thought and information transfer.
I think “significant decrease in readability” is interpreted a little too literally here.
Many of the documents linked by fouric would be way more inconvenient to read if they were adapted to fit in gemini’s limitations because of how heavily they rely on tables, anchor links to a specific part of the same document, and inline images (especially with how inconsistent most clients available today are at dealing with non-gemtext content types).
I personally am a big fan of how gemtext files only ever result in a single request due to the lack of stylesheets, scripting, and inline resources, and have pushed back on the adoption of HTML and Markdown as alternate document content types because I think that is a valuable part of the protocol. I’m also not delusional: the stance I hold also directly limits the mass appeal of gemini as a technology, because normal people who just want to read these kinds of documents are unlikely to accept what seems like massive inconvenience for technical reasons they don’t fully understand. They’ll just stick to the Web.
I am willing to put up with that inconvenience as a reader and writer of gemtext content because I think the other benefits of gemini are worth it, but I don’t expect anyone who isn’t another disillusioned Web developer to get on board quite as easily.
This isn’t quite true, is it? His comment included the clearly-delineated metadata of his name and the time, including an inline graphic element (his avatar) to aid the eye in scanning the page for it. Gemtext as currently defined precludes any such niceties because they are perceived as ornament by the early community (who ironically see a need for some headings, lists, quotes, and … ASCII art).
It also included a simple method for you to add a reply. POST is a slippery slope, but I hope Gemini someday gains a sort of Micropub.
(I am one of those $FEATURE users, where $FEATURE is inline images and metadata or some sort of “secondary” text. But I’ll finish building my capsule and client and see how things evolve.)
How would metafilter-style writing look, with lots of inline links? Examples appreciated.
You just wouldn’t have lots of inline links. You’d have a separate list of references, perhaps. Here are some examples of Gemini posts I have written with lots of links:
https://portal.drewdevault.com/2020/11/01/What-is-Gemini-anyway.gmi
https://portal.drewdevault.com/2020/10/22/Firefox-the-embarassment-of-FOSS.gmi
https://portal.drewdevault.com/2020/10/01/Spamtoberfest.gmi
Let me put it this way: how would inline links work in a newspaper, book, or magazine? The answer is: they wouldn’t, and you just work within those limitations. That doesn’t mean the medium is bad.
Not arguing against you, but when it comes to web browsers, then they still haven’t learnt to properly hyphenate text. Another thing we could do 150 years ago. One of the reasons (another being rather poor support for rendering maths, or, in the case of Chromium, complete lack of it) I’m relieved whenever I get to read a PDF generated from LaTeX instead of a webpage.
You can manually hyphenate with soft hyphens like you did 150 years ago just fine.
Automating hyphenation is nearly impossible. LaTeX certainly requires some manual help.
If I use soft hyphens, then copying
He­re are rhi­nos.to terminal results inHe re are rhi nos.visually, because it copied the text with the soft hyphens even though everything was on a single line.It never required it when I used it. When you enable correct language support, it should just work.
That’s because your terminal is 1970s computer technology.
No. That’s because I copied text, but received bytes instead.
FWIW it doesn’t happen with
hyphenate: autoin CSS, but that’s only supported by Firefox, so it’s irrelevant.150 years ago you couldn’t copy manually-hyphenated text from your newspaper in to your terminal.
I thought this analogy was cute for a little bit. But seriously, why is 150 years ago the standard? Are we really that painfully nostalgia-blind that we can’t recognize there’s a medium point between the old and the new?
It isn’t my standard, and frankly I don’t really care what we could / couldn’t do 150 years ago because I don’t believe it matters in the context of what are we doing, trying to do, and can’t do today.
Firefox does hyphenation with
hyphens: auto;if you set the document language.Does Gemini support setting the document language?
A quick search on the specification shows it does. So hyphenation working on gemini or not would be a matter of the client implementing it.
Well, 150 years ago it was a manual process, and not an automatic one :-) I regularly insert
­for this on my website by the way. But yeah, I agree that the lack of a universally supportedhyphenate: autohas been long overdue (only Firefox supports it, and it doesn’t even do a great job at it, although I don’t know if there are technical reasons that prevent it from doing a better job; I think I saw someone on HN detail some issues with automatic hyphenation on the web years ago, but I forgot what they were).Math rendering has also been supported by Firefox for 15 years with MathML, but for some reason Chrome doesn’t (but Safari does). Actually, looks like they removed it in Chrome years ago, although it looks like there’s work to add it back soon-ish.
Actually, along with Firefox, some versions of Chrome (Android & Mac) support auto hyphenation, and Safari has it hidden behind a prefix: https://caniuse.com/css-hyphens I feel that together these may cover enough of the market to make it worth adding to web pages.
If you want to see a quick and stupid demo, here’s my very unfinished Hugo theme I’m working on developing: https://www.maximumethics.dev/blog/2020/07/my-first-post/ If you shrink the viewport width until it’s skinny like a phone, you’ll see the longer 90 chars “alphabet” line break to hyphenate (on the aforementioned supported browsers), as well as random words in the text.
Ah yeah, it’s just the desktop version that doesn’t support it for some weird reason; I forgot about that detail.
I suppose it depends what you use it for: most of the time I really wanted auto hyphenation is for comparatively narrow pieces of text and/or for
text-align: justify(e.g. a sidebar or info box). In those cases the hyphenation (manual or automatic) is pretty much a must-have rather than a nice-to-have, because without it it just looks ugly. Your site, on the other hand, looks fairly decent without hyphenation even on smaller screens, but it won’t hurt to add it for browsers that support it.That’s what I was on about. If something isn’t available in Chrome, it’s irrelevant these days. I’ve been aware that “it looks like there’s work to add it back soon-ish” for quite some time now. I don’t have hope.
I think the idea is that the publisher delivers only the information, not the presentation. This constraint allows for greater user control over presentation, for example one might configure Gemini to lay out news articles (maybe on a site by site basis) in a column style, to suit their preferences. I think it’s an interesting idea as a way of making better typesetting more widely available to content published on sites without the budget / know-how to tune their CSS for readability.
I agree that Gemini would be better off if it supported inline images. That’s pretty often part of the information layer.
Wait! That is HTML! (as compared to PDF)
Not really, HTML still focuses a lot on presentation. Headers, side bars, footers, nagivation line, footnotes, etc. are all concepts foreign to the browser, that have to be manually re-implemented in the markup language, again and again. That’s actually what I think that protocols like Gemini misunderstand: HTTP/HTML is not too systamatically complicated (at most it’s “organically” complicated), it’s actually too simple. If for example the
<head>section had made it possible to describe how a web-page is navigated, it would have been possible for the browser to render that part of the site, leaving the<body>to be actual content. It’s something you see with other simple languages too: Scheme has various implementations, that implement a common core, but diverge in their additional libraries, that are regarded as useful, but do not allow for code to be portable. So too, had HTTP/HTML has the foresight to recognize what people would want from websites (which is probably too much to ask), or at least the foresight to allow a certain degree of extensibility, a lot of implementation-specific complexity could have probably been avoided.So the issue might not be “simplicity vs compexity”, but “what kind of complexity”.
Years ago I came across a browser extension that would build a navigation bar if it found certain
<link>tags in the header. I modified my blogging engine to automatically add said links. Sadly, the extension no longer runs (because of course the extension mechanism changed—at least twice—since then) but I still generate the data in the vain hope it’ll be useful again.A strict separation of information and presentation is something that sounds great in theory, but doesn’t really work all that well in practice once you move beyond the simple use cases, or use cases that are pre-defined and supported in some way.
I don’t know if this was part of the design goal - from what I can see, Gemini doesn’t have any sort of mechanism to describe or annotate what content/information is being delivered, which would make any presentation strategy necessarily heuristic, as there would be no way to delineate e.g. where the “author” of the article is.
I guess you’d just put that information into the document itself.
One underappreciated tag in HTML is the
<address>tag, which is a nice place to put stuff like author, publication date, etc.I’m not quite sure what you mean - when you say “just put that information into the document itself” do you mean in a machine-readable format? Because if so, that’s not part of the Gemini text spec - which is the thing being discussed. Adding tags like
<address>would be extending the Gemini spec to add features, which is what proponents of it are fiercely against.No, I just meant to add something like
in the body of the text somewhere.
As it has been stated on the mailing list, “you can always serve up text/html or text/markdown, you aren’t limited to text/gemini.” There are sites out there serving up images and even music.
Well, that’s not really what’s advocated for in this post (or on the Gemini website as far as I could see), and serving HTML over Gemini just sounds like a
s/HTTP/Gemini/, and you can serve text or Markdown over HTTP as well. I don’t really see the point if you’re going to serve HTML over Gemini.I’m sick of how complex html+css+js gets, and how complicated extracting the actual content can be, in order to view it on “unusual” platforms (small screens. ereaders, etc.), where a good experience depends on the client controlling the presentation of the content. Something like gemini could be the solution to that, but I have to say, the lack of inline images is a deal-breaker for me.
I view multi-column layouts as part of the presentation, not the content (I don’t want two columns of text on a phone screen: if I do want two columns of text on the desktop, I can write that into the client), but the images are part of the content.
I did wonder whether technically a gemini-ish client could fetch urls which look like they point to images and display them inline, but this is explicitly banned by the specification:
I can sort of see what they’re aiming for, presumably trying to avoid the sort of nonsense some websites have become, where the initial request just gets a jumble of html elements that require the client to fetch and execute tons of javascript before they can be assembled into something resembling content, but I think they should have made an exception for images (They could still leave it up to the client whether it displays inline images or not).
Interestingly, gemini probably works really well with screen readers, until you get to an image link (or any link for that matter), at which point it depends entirely on whether the author bothered to provide a caption, or explain what the link is as part of the text (Although that’s arguably no worse than html, where the existence of alt text doesn’t mean that it is always used or used correctly).
Another reason to not allow non-user-initiated network connections is that’s abused to track users (Facebook pixel etc).
IMHO this could be sufficiently solved by allowing additional requests to the same domain as the document request.
One big reason I’m excited about Gemini is the possibility of escaping the web’s bloat, which we need to do in order to reduce energy usage / emissions in the climate crisis. For this reason, I support Gemini’s decision to ban inline images. If you have inline images, next people will want inline video, and soon even if Gemini is “simpler” it’s using as much storage+bandwidth+processing as a web page.
Inlining images, especially from other locations, is also a plausible method for sneaking user tracking back into the protocol, and I also approve of Gemini’s strong efforts towards privacy. I also hate ads even when they don’t track people, I’d love to live someplace where billboards are banned so I can escape the constant background hum of marketing. Eliminating inline images is also a great way to reduce the annoyance of advertising.
I’m going to have to agree with everyone in this thread that refusing to implement inline links was a mistake, though. That was one of the biggest problems I had with Gopher, and I was hoping Gemini would do a better job with hypertext.
It’s a very difficult balance to strike between simplicity and functionality. You could probably avoid trackers by, as @m_eiman says, only allowing additional requests from the same domain as the original document.
Alternatively, you could create/use a format which embeds the images directly in the original document (similar to how pdf or epub does). Some might argue that this is inefficient, as you need to serve multiple copies of the image data if it appears on multiple pages. However, in this context, it could be seen as a feature, as we don’t want the kind of images (such as ads) which aren’t actually “part of the document”.
There will always be some people who abuse any protocol, but not having inline images is very limiting and means it isn’t any good for a significant portion of (what I consider) “good content that doesn’t need javascript/css”.
I’m just going to drop a link to the FAQ page, in the hopes that it’ll answer some questions here.
Might I ask what’s wrong with merely providing a link to the image?
This can be easily done with some ASCII art (which is what you do for Markdown, anyways) coupled with a preformatted block.
But ASCII art is pretty much the quintessence of mixing presentation and content, which is very specifically what Gemini seeks to avoid. It can’t wrap or scroll differently on small devices, it can’t be extracted (easily and reliably) to a machine-readable data format, and it isn’t accessible because there’s no semantic information about the table structure.
You’re right. I kinda hope some kind of table syntax does make it into the Gemini spec after all.
I need to click a link to an image? It seems pretty obvious to me that this is worse UX than just displaying it.
ASCII art relies on a monospaced font, which I don’t really like for reading text. I think Lobsters would be significantly worse if it was all monospaced text for example. It also relies on a certain screen size, which doesn’t work for smaller screens (or very big ones, for that matter). I mean, it kinda works but it’s a hack.
Yeah. You’re completely right, this is worse UX. I’m beginning to think of proposing an inline-image syntax for the gemini spec.
I admit I was wrong. ASCII tables are a hack, I suppose. Hopefully the simple table syntax I’m thinking of right now makes it into the spec!
FYI there are gemini clients that support variable-width fonts.
I tried to use it with Gopher years ago (I hacked up an existing client), and many sites don’t really work all that well because they assume stuff will be displayed as monospaced text (such as tables you mentioned, but also things like code examples, or other alignment things).
Gemini is a bit of an improvement because the spec at least recognizes that proportional text exits and has “code blocks”, but it also leaves much to the clients. In other words: I wouldn’t be surprised if people would just keep using it as they used Gopher, and the weird (and IMO, broken) way line wrapping works in Gemini doesn’t help either. I suppose time will tell how it will be used in practice (but as mentioned, I don’t think it will be used much in practice beyond a few “Hacker blogs” like Drew’s).
One of the big mistakes of HTML was, ironically, to “leave it up to the clients” which resulted in a big mess which had to be unified so that people could get a reasonably consistent experience irregardless of which browser they use, but that just unified the mess instead of clearing it up.
I use HTML to add tables to my Markdown content.
I personally find HTML’s table syntax difficult to read and use.
Yep, I usually whip up a quick Perl script with the (deprecated)
CGImodule to generate it from plain text ;)Gemini is only a protocol, but the specification also propose a basic text/gemini format as a de-facto document type. It however supports any mimetype, including text/html:
You could totally sent the following HTML document over gemini:// and enjoy inline images:
It would then be up to the gemini client to process this document, fetch required resources (the cat picture) and render it nicely for you. The advantage of the gemini protocol here is that it would put a limit on the HTML subset one could put in a document. For example,
<form>tags won’t be any useful. There would also be no need for<script>tags, as they wouldn’t be able to “phone home” over gemini.One of the biggest problem of the web is that the HTTP protocol itself grew in an enormous monster that’s impossible to understand, where sometimes the headers of a requests can be 10 times bigger than the content itself.