💾 Archived View for idiomdrottning.org › gemtext captured on 2023-06-16 at 16:58:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
➡️ Next capture (2024-02-05)
-=-=-=-=-=-=-
See also: An eight-line summary of Gemini’s markup format
To tie into some of my earlier posts on this, here’s how I see the purpose and limitations of Gemini’s text format.
A lot of formats have limitations.
On a printed paper page, you can’t easily reflow the text or change the font, or have metadata like alt or rel.
WHen sending an SMS or text message, you can’t easily set the font.
No one is complaining that you can’t enforce a multi-column layout on a text message.
And while there are ways to do those things on email (via HTML email)… that sucks! It’s awful to read email when every mail is its own color scheme or font size. Even web pages are starting to get annoying for the same reason.
Texinfo and DocBook are early examples of source languages that were designed for outputting more than one target.
You could write in the source format and export a man page, a pdf, or a set of webpages. That was really eye-opening to a lot of people.
roff itself was made both for typeset, printed pages and for man pages.
What happened the last two decades, after the failures of YAML but the successes of an ever-extending, nebulously defined markdown, is that the expectation is that every language, even languages that look like (on the surface) like simple text languages, need to be a universal source language. Every language needs to handle every feature.
But, they don’t.
Gemtext does not a have to be universal source language.
If you do have content that is somewhat lossy to write in Gemtext (for example you have italicized words or you have a specific layout), it’s fine to put that in a source language and generate gemtext from that, and a book or whatever also from that. And the book could preserve the typographical detail or layout detail while the gemtext version has other benefits.
Don’t get me wrong here. I’m not advocating that everyone needs to start doing that. If what you want to express fits in gemtext, and you are writing it in gemtext, please keep on doing so.
No one would be advocating for the widespread use of a cockamamie Rube Goldberg Markdown conversion scheme for things like text messages, YouTube comments, or gemlog posts. Keep it simple, sweetie.♥
If you want to use the same texts for something else, though, that’s when you might want to look into source languages.
Since Gemtext is so simple, and hard to mess up, it’s possible to typeset it gorgeously in the client. As much as people try to separate HTML’s semantic markup from its presentation, we still see completely messed up things like sites drowning in very deeply nested divs, or only generated on the fly with JavaScript, or (and Markdown is guilty here!) using em when they mean i, for things like Latin names.
That’s not happening as much on gemtext. That’s a huge win!
It’s just a very, uh, “mashable” and reliable format.
As I wrote the other day (linked above)
Gemini finally solved the semantic vs presentation problem.
Although, grumble grumble hardwrapping! In hindsight, gemtext’s wrapping semantics were absolutely a bad decision in the context of the “reliability” of gemtext, the “you can’t really mess up the semantics”–ness of it…
It doesn’t have any in-line markup that can fail, such as emphasis or hyperlink that doesn’t get closed.
Before gemtext, semantic markup depended on everyone being smart and never messing up.
(If I had a nickel every time I personally saw someone just putting bold&big when they mean header, or vice versa, I’d have almost three million dollars. Uh, a nickel is five cents, right? Then yes.)
Gemtext is way more mess-up proof in that regard and that is what we need for the future of the web.♥
But. The simple act of hitting carriage return when writing a paragraph can render the whole thing borked up.
Being able to link to alternate formats, or designate something as creative commons, that’s something I do miss. I get that having those would be adding areas where people could mess up. So I get why that’s not there, but that means that trying to do those things is still an open problem. I think this is another of those square pegs and round holes situations. If I stick with the premise that gemtext is a target language rather than a source language, metadata doesn’t necessarily need to be on the gemtext pages themselves. It’s just difficult to find the metadata for a given capsule.
At first, I also missed rel next and rel prev but with the “tree”-like structure that gemtext is suited for, I realize that I’d be tryna push a square peg into a round hole.
Next and prev can be understood as the next and previous link on the parent page—the page that led one here! They don’t need to be on every page.
So next/prev is not a failure as far as I’m concerned.
lapingvino reminds us of Fountain, another successful source language that transforms into a simple export language.
Markdown for a different purpose (gemini text and Fountain)
The unfinished script I started writing last fall but hasn’t finished yet uses Fountain. Via Emacs’ fantastic fountain support.
People filling their text lines with *asterisks*, /slashes/ and all kinds of comicana @#$%^ is fine as long as no Gemini client starts rendering that or respecting that in any way. If it becomes “markup” though, that’d be breaking Gemtext. But that’s a failure on the behalf of that client writer (since they’d be embracing&extending). Expanded-by-default images would be another problem (since a similar feature in the 90s lead to peolpe using images for text since they wanted fancy fonts and layouts that the primitive 90s web didn’t support. That was way worse than CSS).
Header levels, on the other hand, is an area where people can mess up.
Please don’t skip header levels. Put # in the top, one per document is ideal, and then ## under that, and ### under those.