Follow

What if... we had Markdown as a first-class citizen of Geminispace?

gemini://skyjake.fi/gemlog/202
gmi.skyjake.fi/gemlog/2021-10_

I'm feeling a bit conflicted about this, but ultimately it's up to you to decide which format suits your content the best.

@lutindiscret Yeah, using a well-defined spec as a reference is certainly the wisest approach.

Although I wouldn’t want to implement the full CommonMark spec in its entirety…

@jk well partial support is quite a pain for content creator.

If you can't write something without being anxious about it not being rendered correctly in some browser (and when you fix, it breaks in other browsers...).

You might be recreating what made the web a painful platform: spending more time to fix browser-compatibility issues than enjoying content creation. IMO, that would break what makes Gemini more enjoyable than the web for content creators 😔

@lutindiscret That's a very good point. Gemtext is always there as a hassle-free option, though.

Fully supporting Markdown essentially requires a web-grade rendering engine, and that is out of scope for Gemini IMO. That's why I discuss a "Gemini-flavored" Markdown in the gemlog post.

Also @jk, if you choose this path, please at least, don't have a "quirck mode" and make Lagrange do not print anything but an error message if the document has syntax error.

Allow rendering of poorly structured content is what made the web full of broken pages. Fail early will force creators to make things properly. I don't want "this gemlog is best rendered with <insert-not-my-gemini-browser-here>" to be back from the deads.

@lutindiscret Is there a way to validate CommonMark so as to detect if anything is a syntax error? I've been under the impression that there's basically no such thing as syntax errors in Markdown; everything will yield some sort of output.

When it comes to formal structured languages like HTML, I agree it's important not to bend the rules, as the history of the web has demonstrated.

> no such thing as syntax errors in Markdown

@jk I think you have a point 🤔 I can't think of any.

@lutindiscret @jk Well, the CommonMark specification contains hundreds of tests so you can write automated tests to determine whether your implementation conforms to the spec. But that’s what a syntax error would end up being, right? The wrong HTML. I did that for my own Markdown implementation – and then despaired and never finished it once I had ported all the tests.

@lutindiscret @jk in any case I like the idea of the server offering multiple well defined formats much better (as per the last post). It’s what I do as well. They all serve “raw” (which is a kind of Markdown, I guess), HTML, and gemtext. For those sites of mine where Phoebe is just the front end and Oddmuse is the backend, the raw text can be very different from gemtext and might also convert less well… but that’s what it is. Conversion warts and all. The onus is on me, not on clients.

@kensanata you are right. Writing a parser is very hard, even for "simple" languages. If I had to write a CommonMark → Gemini parser, I would take a conforming parser (like github.com/markdown-it/markdow) and just replace the functions that write a HTML markup element by one that does gemini replacing only the very last step of the parsing library. So many broken implementations exist, one should not add more misery to the world...

@jk

@kensanata @lutindiscret The tests are certainly very valuable, but I think the issue here was more about browsers somehow being able to reject invalid content, like an XML document could be rejected if it wasn't well-formed.

@jk this scares me, especially in lagrange which seems to have the largest client following. I'm glad you're limiting the set of decorators you're allowing and not including things like inline links, but oof, it's scary.

Markdown basically is HTML, as you point out. Once that nut gets cracked open we have to face the question, "does content in mime-types other than text/gemini allow for nested requests?" Does the image pre-load in Markdown? And if that happens, is there any functional difference between Gemini and HTTP? Yes, there's a slippery-slope argument and that's a fallacy, but in this particular case I think we are literally dealing with a slippery slope.

You're dipping your toe into it for richer text formatting. It's something people have talked about before. Clients were bound to do it eventually. I dunno... it's just scary.

@tomasino It’s good to be careful here for sure.

One should not conflate page content and the protocol, though. A richer-formatted page is still served over Gemini, with its single request rule and no preloading. Even HTML can be used outside the context of a full-blown web browser, although I’m not sure anyone would want that.

IMO the biggest danger is fragmentation. If people don’t see the value of standard Gemtext as the glue that holds Gemini together, the community splits apart.

@tomasino In any case, I’m not planning to rush into adding non-Gemtext-based document formats to Lagrange. There are more important short/medium-term things to take care of, and there is also a maximum size for the code base that makes sense for a single developer.

@jk @tomasino All I can say is that I added HTML handling to my Elpher installation so that I could move seamlessly from Gemini browsing to HTML browsing without breaking the UI (and before that following a HTML link only took me into the Eww, the Emacs web browser, with different key bindings; I'm not leaving Emacs either way); in any case, I don't feel more inclined to follow web links, I still prefer the Gemini interface to my blog… so I dunno, the slippery slope does not concern me as much?

@tomasino @jk maybe we could have something like gemtext but with inline links allowed. I've never fully understood why that's supposed to be so evil

@Hyolobrika @jk i talk about this in my Why Gemini? video. There's going to be a line somewhere where we say these things are okay and these things are too much. Yes, it's arbitrary, but it's essential for a protocol determined not to grow and mutate. No matter where we draw that line someone will say, "by why not this one small thing more?"

Inline links were an easy one to say no to because it simplifies things without really hurting stuff. Gopher has had it that way all along, after all. Parsing is easier. Text wrapping is simple. The mark-up itself is simple.

Why not underlines, bold, and italics? That's a harder one. Again, it's arbitrary. We justify rules like "the first 3 characters define the line" but that's not a real reason. The real reason is there's an arbitrary line that someone drew.

@tomasino @jk I watched that video and it made me want to respond "why is it arbitrary?". To me the line is more clear: will this new feature enable unnecessary tracking in some form? if no, add it; if yes, don't
@tomasino @Hyolobrika @jk

"Clients were bound to do it eventually. I dunno... it's just scary."

I really respect and look to what tomasino's contemplations opine. He has (You, Tomasino, have) been one of the more thoughtful contributors not just here in Geminispace, but also Tlldespace.

That having been said @jk , you do make mention in your paper:

"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?", and "...dumping all non-Gemtext pages to an external viewer is a terrible user experience.", but this is exactly how the spec expects it to be done, and it's how Gopher has done it forever too. I used to install Gopher services at public libraries, back in the days when we believed that we were actually going to replace card catalogs... and yes, that is ugly, lauching an external application based on Mime types to accommodate images and such.

Taking your thought process a little bit further, having native internal support for your published variant of .md files within Lagrange, perhaps a superset .md file that offers those authors the additional formatting you're seeking to accommodate?

Just thinking out loud here, but I do support where you're going with this notion, and there's this:

https://pleroma.cloud/notice/ACTbW16Yn1dBY1JEDg

I'll certainly be following closely and like I said, my interest is piqued.



.

@tallship @Hyolobrika @tomasino

There is still more to experiment with here, but yeah the idea would be to eventually have some flavor of Markdown that is natively displayed in the app. It would still be subject to every rule of the Gemini protocol.

This reply turned out quite long for Mastodon; continuing here:
gemini://skyjake.fi/misc/2021-

@jk @tallship @tomasino Btw, Pleroma has no built-in character limit. Gemini links don't seem to work as well though.
@Hyolobrika @tomasino @jk

gemtext is mostly line oriented, which makes it dead easy to parse. has very limited syntax which makes it easy to learn. my partner is a cook and she learned gemtext in five minutes. there might be room for more features, but my partner is going to get fed up with it if new stuff gets added periodically. i don’t know where the complexity ceiling is, but i also don’t want to find out because i’m below it already.
@Hyolobrika @jk @tomasino back when she was on reddit, she could never remember how a link worked or ever memorize markdown. it’s just too complicated.
Sign in to participate in the conversation
skyjake.fi

skyjake's personal Mastodon instance