-- Leo's gemini proxy
-- Connecting to ew.srht.site:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
> There is a subtle point about a Gemini limitation here. Abusing Unicode for stylization became common as a hack to allow bold and italics text on plain text-only social media. We see the same trend of Gemini, which also bars formatting. Perhaps if Gemini supported semantic bold and italics via Markdown-like syntax, Geminauts wouldn't feel inclined to reach for the dirty tricks to get there instead. Paradoxically, this could return control to the user, by allowing bold and italics to be softened or removed altogether when presenting, although bad actors might still spoil it but bolding entire web pages and such. Alternatively, the fact that Gemini allows arbitrary Unicode at all is at best an oversight. Either way, this needs attention.
I completely agree that this needs attention, and that abusing Unicode characters is mean (even if that was never the intention). But what do we do about it?
Feature suggestions around gemtext get shot down on the gemini mailing list on a regular basis. Some discarded suggestions I can recall off the top of my head:
Nested lists.
Emphasized or bold text.
Tables.
Inline links.
Numbered lists.
Why are suggestions like this discarded? Usually because of these reasons:
Gemtext parsing is line-based. Anything that's inline clashes with parsing.
Gemtext parsing is generally context-free; each line is independent of the previous or following lines, with pre-formatted being the one exception.
Right now there are only seven different line types in gemtext. Even if each suggested addition is "just one more line type" it would quickly add up to a lot more complexity.
The strict limitations of gemtext, when respected, make it superbly accessible in general and easy to both read as is and write parsers or converters for. Converting to gemtext is lossy, of course, but converting from it is a breeze.
See how I could have used an emphasis on 'to' and 'from' there? When not emphasizing those words the text becomes a little different in tone, but not really in meaning.
My general contention is that gemtext is good enough. It's never going to be enough for every use case, but it's not trying to either. I've decided to lean into its limitations and make the most of it, and superbly enjoy it. I totally get that people would like more features, but I think it's better to think differently of it.
Do you want nested lists? Maybe lists aren't actually the best fit for what you're writing? Maybe the top level of your list should be a heading?
Do you want tables? Small tables can be inserted in preformatted blocks, formatted with the help of an external tool such as columns. For accessibility I think all tables should also be supplied as a CSV file or similar.
The hurdle to get over here is something that we take for granted from the web: that the content author wants power of presentation. You and I, as content authors, should not. Internalise that mindset. If you do want control over presentation, there are several options:
Provide the content in pdf format.
Provide the content in html format.
Provide the content in an image format.
Provide the content in...
Well, you see my point. The biggest fallacy around gemtext is that it's supposed to be the only content format in geminispace, or that it's supposed to support all types of content. I realize that I come off as a grumpy conservative here, but that's not my intention at all. It's not that I want to never add anything to gemtext ever, but I have yet to find an addition that I feel is worth the extra complexity.
By the way, I find the abuse of ANSI escape codes even worse 😆️
-- CC0 ew0k, 2021-04-05
-- Response ended
-- Page fetched on Fri May 3 21:00:06 2024