💾 Archived View for gem.sdf.org › jdd › posts › 20220416-rules.gmi captured on 2022-04-28 at 17:38:49. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
<2022-04-16 Sat>
Thoughts in reference to:
Gemini Spec compliance - my anarchist take (StackSmith)
Like a lot of other people, when I first encountered gemini I thought the rules were somewhat capricious and arbitrary. Sure, I get why there's no CSS, cookies and javascript, but ... Why is markup so limited? Why no inline images? It didn't really make much sense to me. And you know what? It still doesn't, not really. Would markup for italics, bold and underline really be so bad? Or even, gasp, tables?
So my first inclination with gemini was to see how much I could push against its constraints. In this, I was inspired by Yeti's wonderful unicode art:
But then, as is my way, I began to second-guess my initial reaction. Why not accept that gemini is the way it is and give it a try? I unpublished my pallid imitations of Yeti's artwork, and began writing gemlog posts just like (almost) everyone else. And came to the conclusion that gemini is fine, for what it does.
Would extensions to the markup make gemini more useful? Undoubtedly. But as Alex's Gemlog reminds us, utility probably shouldn't be the goal here.
Gemini is useless (Alex's Gemlog)
In the endless discussions around how gemini ought best to be extended, there's a giant ... elephant? octopus? spider? ... in the room. We often refer to it as "the web". Pretty much all of stuff we're trying to get away from began its existence as a way to make the web more useful: cookies and javascript have totally defensible reasons to exist. The same arguments that are being made to advance inline linking and markup enhancement in gemtext could be used for session cookies and client-side scripting languages. (Yes, I'm aware that's a "slippery slope" argument, but hey, we've already slid down that slope several times already so it's not entirely outside the realm of possibility that it could happen again).
Love it or hate it, one undeniable fact about the web is it's already here. You want bold, italic and underline? You want inline everything? You want tables? You got 'em. If these things are important to you, there is already a markup language that does all these things and much, much more. Why is it necessary to add features to gemtext when all the markup you could ever want is just a link away?
We can spend the next 20 years turning gemtext into HTML (arguing all the way), or we can just use HTML ... or pdf ... or markdown, where appropriate. I know which approach I'd prefer. The idea of a "finished" protocol with arbitrary constraints is actually far more new and interesting than revisiting the browser wars of the 1990s, where competing client-side innovations drove the evolution of the markup. That's one aspect of 1990s computing I'm not nostalgic for.
A couple of concluding thoughts ...
When considering the possibility of enhanced gemtext, ask yourself: was HTML email a good idea or not? Yes, this was a matter of some debate back in the 90s, and if we're going to back to the browser wars maybe we should dredge up this old chestnut also. Maybe there are lessons for gemini there. [1] (I'm of the opinion that HTML email was a pox upon humanity, myself).
Also, I understand too many posts like this one have recently driven Drew DeVault away from gemini altogether.[2] Which is too bad, as I really enjoyed his contributions to geminispace. And for which I can only apologise, although I have only written a small number of such posts myself. While I doubt I would be capable of writing the long-form technical content that would hold his interest, I can at least make a commitment not to write anything more about gemini for a while. As far as I'm concerned, gemini has attained its final and (im)perfect form, so there isn't much more for me to say along these lines.
[1] Why HTML in E-Mail is a Bad Idea
[2] Stepping away from Gemini (Drew DeVault)
gemini rules was published on 2022-04-16