Brian Evans writes: > I think think many clients will opt to implement markdown parsers > (heck, some may even try html parsing), but I think it would be a bad > call to include it in the spec for gemini. Now that it has been > brought up, I may add markdown parsing to the client I am working on > (I am still in planning stages figuring out how I want it to work and > the necessary structs and execution flows). I am of two minds on this. On the one hand, I am generally of the "pave the cowpaths" school, where your RFCs ratify actual practice and pick out best practices. On the other, I would not like to see Gemini usage split early on between Markdown-implementing sites/clients and non-Markdown-implementing. Personally, what I would most like to see in a client is a large subset of Markdown (no embedded HTML, probably no inline images). But all of the CommonMark text properties, levels of headings, etc. In general, I would like for reasonable typography to be what you think of when you think of a Gemini page. I understand that this makes things significantly harder for client implementors. That's one reason why I've suggested ratfactor's Text Junior format (can someone invite ratfactor? I don't have any means of contacting them) as a standard format for Gemini. It is basically a large subset of Markdown, but fully line-oriented and stripped of parsing ambiguities. A simple client can either just cat(1) it, can fmt(1) everything that's not wrapped in a ``` ``` block, or can apply full formatting. Everything I have served on my Gemini site is legal Text Junior. It is perhaps unfortunate that despite there being Markdown parser libraries for every common language, practically all of them are focused on generating HTML rather than generating (e.g.) a parse tree that you could use in your own layout engine. If all of those libraries had better support for other representations, I'd honestly argue that we just use MarkDown (CommonMark), because it already occupies the text-formatting analogue of the niche that Gemini is aiming for in the protocol world, IMO. -- +----------------------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | The scalloped tatters of the King in Yellow must hide Yhtill forever.|
---
Previous in thread (8 of 148): 🗣️ Brian Evans (b__m__e (a) mailfence.com)
Next in thread (10 of 148): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)