> I both agree and disagree with the above sentiment. I agree the basic > gemini file structure that has already been preliminarily approved does > solve many of the issues people find with gopher (at least when combined > with the response header/mime). I like this fine and am still happy to > move forward with it (though some minor markup would be neat). I am *super* happy with the extent to which Gemini as-specced solves common complaints/pain-points with Gopher. Lack of text reflowing is, I think, the *only* even half-way common Gopher complaint/limitation where we haven't made really very major progress. For everything else, we've knocked it out of the park. > I had written a lot more here in support of markdown... but the more > I thought about it the more it felt like a separate concern. It might be > a good idea for a few developers that are planning on making feature > rich clients get together and try to standardise on some form of > markdown support so that a community standard can arise without > the need of it being included in the gemini spec itself. If things went > that way I would advocate for keeping the gemini file format (with > the line based links) so that simple clients can still be built. If people wanted to produce, as a kind of parellel project, a complete and detailed specification of "Markdown" which lacked anything gross (like embedded HTML), I think I'd be happy to have the Gemini spec say "Gemini clients which opt to support text/markdown responses should do so using such-and-such definition of Markdown", referring to the results of that project. -Solderpunk
---
Previous in thread (6 of 23): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (8 of 23): 🗣️ julienXX (julien (a) sideburns.eu)