💾 Archived View for rawtext.club › ~sloum › geminilist › 004659.gmi captured on 2023-11-14 at 10:40:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
John Cowan cowan at ccil.org
Sun Jan 3 00:16:09 GMT 2021
- - - - - - - - - - - - - - - - - - -
"User" editors usually don't generate HT when the user presses the TAB key.
On Sat, Jan 2, 2021 at 4:35 PM <nothien at uber.space> wrote:
There is a new discussion about table formats under the [users]
category, but I've thought of one possibility that roughly matches the
look of tables but keeps each cell on its own line, and I wanted to see
what 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 a
preformatted block, but it's the best way to show that it's an
unfamiliar 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 |
+--------------------------------+-------+
```table
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, and
should be very easy to parse programmatically as well. Of course, it
would be more difficult to visualize with more columns and longer cell
texts, but it's (much) better than nothing.
Each cell is on a different block, and the general expectation is that
the indentation level increases by one horizontal tab for every next
column, then resetting to no indentation for the next row. We could
probably give specific interpretation to other possible things that
happen (e.g. 'jumps' in indentation level which are not resetting to
rows), or we could outright ban them, but I would prefer the former (as
then there is no room for extension).
I know that we're looking to finalize the spec, and that this will
probably not make it in (even if it gets accepted). Tables are quite
uncommon, after all, so I don't there would be a big enough push to
warrant making it official. But I argue that tables are a very
difficult thing to format to satisfy both humans and computers, so at
the minimum we would add this (or any agreed-upon table format) to the
best practices document. The best-case scenario to me is that it gets
added to the gemtext spec as an optional type to parse, similar to how
one would parse other preformatted blocks (but with more state to keep
track of).
What do you think?
~aravk | ~nothien
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210102/80f9e9d3/attachment-0001.htm>