💾 Archived View for skyjake.fi › gemlog › 2021-10_mark-it-down.gmi captured on 2024-06-16 at 12:20:36. Gemini links have been rewritten to link to archived content

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

Mark It Down

Perhaps you've encountered this sentiment before:

Gemtext is so _restrictive_! How on Earth am I to convey the nuance of my writing without being able to **EMPHASIZE** words?

To which the response is:

Just use Markdown or HTML if you want richer markup.

But most Gemini clients don't support Markdown or HTML...?

While regular prose can make do with basic ASCII markup, the more technical you get, the more value there is in having more formatting available for things like class names, file paths, and book/movie titles. It's all about maximizing readability.

Gemtext and Geminispace

The intentional limitations of Gemtext are there to make parsing simple and unambiguous, at the expense of discarding conventional typographical tools available to writers. This equation is strongly biased toward software developers, so they may more easily create programs for processing Gemtext. However, authors do also benefit from having a syntax that's simple to learn and has no hidden gotchas. (Except maybe BOMs. 🙄)

I've been wondering how inextricably linked Gemtext is to Geminispace. Sure, the protocol can serve any other type of content as well, but does it make sense to serve pages in a format that virtually no client supports? Would it help or hinder the community as a whole if a significant amount of content was in a format other than Gemtext? Having everything be Gemtext-only certainly has its upsides, but it sets an inherent restriction on what kind of content can be viewed conveniently via Gemini — dumping all non-Gemtext pages to an external viewer is a terrible user experience. Gemtext purism can also become a gatekeeper of sorts, attracting mostly the ascetic type of users. (Not unlike Gemini itself, I guess.)

Expecting clients to natively support more than Gemtext raises the floor of how much work is required to implement a client. When will the floor be too high? Sure, we probably don't need every person in Geminispace to write a client, but part of why we're here is to get away from the world of impossibly complex browser apps, taking back control of what has been lost to giant corporations. It's crucial to keep things manageable by individuals.

Space-themed markup

There aren't many formats that go hand in hand with the Gemini ethos. The closest is perhaps Markdown — Gemtext can accurately be described as a very limited subset of it. But Markdown was conceived as a nice way to write HTML, complete with the ability to put raw HTML in the document. This makes its feature set quite large. And what's worse, Markdown suffers from fragmentation: there are multiple ways to interpret different elements (underscores vs. asterisks, for example) and many "flavors" have emerged with different syntaxes for special use cases. Robustly parsing Markdown is a bit of a nightmare; it's a night and day difference compared to parsing Gemtext.

For adoption of Markdown to make sense on a larger scale, there would have to be a de facto "Gemini-flavored" variant, i.e., a subset that's larger than Gemtext but definitely not encompassing the entirety of HTML. Such a variant would act as a pressure valve against attempts to introduce new semantics and features to Gemtext. There's a lot of headroom in Markdown for all kinds of useful things, including numbered/nested lists, tables, deeper headings, and horizontal rules.

Transformations

A powerful and flexible format like Markdown is useful for writing the "main" version of a document. It can then be used as a source for generating versions in other formats. Applying a lossy conversion to Gemtext is relatively straightforward.

Assuming one's content management system is amenable to this kind of conversions, this could be a reasonable approach even with a large number of pages. It does add extra steps to the process, though, that don't necessarily need to be there. Granted, an advanced server could translate pages on the fly depending on which file extension is used in the request URL. But still, one is burdened with considering the indirect effects of conversions: will this three-level bullet list be readable at all, for example? Such increases of cognitive load are best avoided.

A Markdown experiment

I've been working on viewing Markdown natively in Lagrange.

Due to the "versatility" of Markdown syntax, I would classify this as experimental for now. In fact, it is more of a built-in Markdown-to-Gemtext converter that knows how to apply font effects as well. There is _no_ support for inline links, numbered or multi-level lists, or other such HTML features. It is (for now) purely a way to view Markdown content using all the capabilities that Lagrange offers as a Gemini client.

Screenshot of font effects

The font effects are entirely based on ANSI escape sequences. While these escapes are intended for terminal emulators, they remain useful as a well-known method of communicating visual attributes. In this experiment they are used for marking up fonts in the internal translated version of the page.

I've supported ANSI colors since the early releases, and now I've added a way to change the font to bold, italic, and monospace. These font resources have been available in the app for a while, and with other font related changes due in v1.8, it is now feasible to apply them in a more flexible manner. Lagrange will support these in all text content, including plaintext and Gemtext (even the UI!).

Typing ANSI escape sequences in a text editor by hand is cumbersome (if not impossible), which should be a sufficient deterrent against their use in the wild. It wouldn't be a great situation if we have widespread use of these as a stand-in for HTML styling tags. In any case, a big upside here is that terminal-based clients can just pass these sequences through to the emulator and not worry about it. On the other hand, this does give control of visual aspects to the content author, but it is possible for clients to either ignore the escapes or apply them in a manner that fits the visual appearance of the client. It should be a net positive.

I will likely include this experimental Markdown support in v1.8. It will certainly not parse and present everything correctly, and will need further work in the future to become a more full-fledged Markdown viewer. Personally, I'm expecting to use Lagrange for reading local Markdown files. However, it will be interesting to see if there is wider interest in having Markdown as a first-class citizen of Geminispace, and being able to view `text/markdown` in a way that is consistent with Gemtext.