> 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. I too would be very happy if Gemini developed a reputation for nice, functional typography. None of the features you propose strike me as problematic. I especially like the levels of headings idea. Not just for the visual aspect, but because it allows, like the Markdown browser you shared a link to, a nice navigational sidebar for large structured documents, which is very much a good thing. > 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. Text Junior seems nice and I'm not opposed to using it or something very similar to it as a basis for Gemini. But the current worst shortcoming, IMHO, of the very minimal "yeah, you can reflow stuff if you like" Gemini spec is that it wrecks nicely formatted lists, and as far as I can see TJ doesn't currently handle that either. -Solderpunk
---
Previous in thread (19 of 148): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)
Next in thread (21 of 148): 🗣️ solderpunk (solderpunk (a) SDF.ORG)