💾 Archived View for rawtext.club › ~sloum › geminilist › 004654.gmi captured on 2023-11-14 at 10:41:04. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[spec] Possible Tables Syntax

nothien at uber.space nothien at uber.space

Sat Jan 2 21:35:36 GMT 2021

- - - - - - - - - - - - - - - - - - -

There is a new discussion about table formats under the [users]category, but I've thought of one possibility that roughly matches thelook of tables but keeps each cell on its own line, and I wanted to seewhat others think of it in a more [spec]-relevant area. Essentially,indentation (tabs) is used to represent which column a cell is in.Wrapping cell text is possible, so I hesitate to put it in apreformatted block, but it's the best way to show that it's anunfamiliar format.

+--------------------------------+-------+

| Food | Price |

+--------------------------------+-------+

| Eggs | $2 |

| Eggs and spam | $4 |

| Eggs, spam, eggs and spam | $8 |

| Spam spam baked beans and spam | $8 |

| Just spam | $2 |

+--------------------------------+-------+


It needs to be tried out a lot more to see how flexible it really is,but it looks promising to me.  It looks quite structured visually, andshould be very easy to parse programmatically as well.  Of course, itwould be more difficult to visualize with more columns and longer celltexts, but it's (much) better than nothing.

Each cell is on a different block, and the general expectation is thatthe indentation level increases by one horizontal tab for every nextcolumn, then resetting to no indentation for the next row.  We couldprobably give specific interpretation to other possible things thathappen (e.g. 'jumps' in indentation level which are not resetting torows), or we could outright ban them, but I would prefer the former (asthen there is no room for extension).

I know that we're looking to finalize the spec, and that this willprobably not make it in (even if it gets accepted).  Tables are quiteuncommon, after all, so I don't there would be a big enough push towarrant making it official.  But I argue that tables are a verydifficult thing to format to satisfy both humans and computers, so atthe minimum we would add this (or any agreed-upon table format) to thebest practices document.  The best-case scenario to me is that it getsadded to the gemtext spec as an optional type to parse, similar to howone would parse other preformatted blocks (but with more state to keeptrack of).

What do you think?

~aravk | ~nothien