What if... we had Markdown as a first-class citizen of Geminispace?
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.
@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 https://github.com/markdown-it/markdown-it) 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 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?
@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.
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:
skyjake's personal Mastodon instance