💾 Archived View for geminiprotocol.net › history › phlog › gemini-maps-2.gmi captured on 2024-05-12 at 15:18:33. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Gemini maps 2

(originally posted in Gopherspace on 2019-06-24)

In response to my last entry about Gemini maps, a number of people have let me know that they don't really like the use of tabs in link lines. In particular, dgold made a post in their Grey Area phlog (which I was previously unaware of!) which has convinced me utterly to abandon the idea.

My 2019-06-23 post about "Gemini maps"

dgold's 2019-06-23 post against the use of tabs in Gemini

The magic bullet was their point 2 on clarity. The simple truth is that it *is not possible* by direct visual inspection of a Gemini map in the proposed format that's printed on your screen to ascertain whether or not a link line is valid - because tabs and spaces, or arbitrary combinations of both, look indistinguishable. That's a nasty misfeature.

It gets even better! This isn't just a theoretical concern. There's a menu item in the root Gemini map at gemini.conman.org which doesn't work because there are *two* tabs between the name and the text. So, there you have it - visual indistinguishability of tab(s) and space(s) has, literally, introduced an accidental error into the *first* ever Gemini map in the world. Case closed: this is a bad design. I'm grateful to dgold for pointing this out so clearly.

dgold proposes the following syntax, inspired by geomyidae:

[UserFriendlyName|LINK]

Amusingly enough, I proposed *exactly* the same syntax to sloum last night when we exchanged some emails about this. I reasoned that it would be familiar not only to geomyidae users, but also MediaWiki users, where a simliar syntax is used. sloum liked it, so the two most vocal opponents of tab-based links are onboard and so I'm going to change the spec-spec to this. I will also update all the code *I'm* responsible for to match this. Sean, please update gemini.conman.org's code when you get a chance. This unsynchronised change will probably result in a small window of incompatibility between servers and clients. Sorry! That's the price of ultra early adoption.

My only concern about this new syntax is that it *looks* like it's designed to be used inline. You'd use it that way in MediaWiki, for example. This might confuse some people at first, although probably not for terribly long.

dgold also isn't happy with some of the ideas I pitched regarding things like rendering headers using MarkDown-esque syntax. I acually disagree very strongly with the idea that control over how content is presented should lie solely with the author - but that's an argument for another entry. However, I'm backing away from the idea of saying anything in the spec about how text should be presented anyway, mosty for the sake of simplicity. Based again on emails with sloum, I've quickly realised that "text can be reflowed" is something which *sounds* simple, but specifying exactly how it should be done would probably double the length of the spec document or more, and it's hardly worth that. Not saying it will never happen, but I'm not keen to rush into it.