💾 Archived View for namno.duckdns.org › blog › 2024-04-23.gmi captured on 2024-06-16 at 12:21:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-26)
-=-=-=-=-=-=-
I have thought a bit, and realized that many parts of such markup are not really necessary.
Box function could be realized with data: URL. So are images, unless they are particularly big. Audio and especially video are probably too big for gemini protocol so it's perhaps best to forget about them.
Inline links could be substituted for „hacker“ „news“ style pseudo-citations, for example:
There are sure some wacky[0] people there => example.com/wacky_person [0]
Some clients could even re-inline those links.
I still would prefer having list items that are not resticted to one line. One hack would be to use NEL (aka unicode character hexadecimal 85) unicode character, since gemtext recognizes eiter LF or CRLF as newlines and thus line terminators. but since it permits line-wraping there is nothing stoping cliets from rendering NEL as character who's with is dependant on how much space is left untill line is wraped. This also allows multiline headers, quotes and links.
Thematic separators, most represented by horisontal lines could be encoded as either headers with no text or as ASCII Form Feed character.
Separation of preformated text that cannot be line-wraped and code that sometimes can is also something I desire, but it can be achieved with a small hack. Clients could scan alt-text area of preformated block and if it follows a certain sequence then it could ignore what standart dictates for better reading experience.
​```<tab><language name><tab><language version>
Need for hover text dubious since if there is really a need for further description one can always use regular brackets.
Need for other inline markers is still up to debate. It's seems hard to represent various versions of emphasis with TTS and it seems even harder to represent text being struck out. And many clients support part of markdown to replresent these stylistic effects.
Subscript and superscript, along with below and above text are necessary for certain notations, but they are better represented inside hypotetical math block.
This leaves only tables.
Tables can be very useful to represent certain kinds of data. One can use markdown csv-ish approach and separate cells with specific character.
One could follow actuall csv standard.
Both of those options do not allow for cells to overlap, with can be a useful feature, especially in headers, but it is not necessary since text inside these expanded cells could be just repeated.
I think that using csv inside code block with rfc4180 as alt-text is a good enough solution.