💾 Archived View for rawtext.club › ~sloum › geminilist › 004663.gmi captured on 2024-03-21 at 16:49:59. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
nothien at uber.space nothien at uber.space
Sun Jan 3 09:02:28 GMT 2021
- - - - - - - - - - - - - - - - - - -
Philip Linde <linde.philip at gmail.com> wrote:
I think that using preformatted blocks as an extension vector for
table data is a bad idea. Preformatted then no longer always means
preformatted.
Yes, I agree, the container format (```table```) is bad. I was moreinterested in the actual format - but we can definitely change thecontaining layout. Do you have any suggestions?
I also have qualms about the suggested format itself because there are
already formats for describing tabular data with a lot of tooling
support. If the goal is machine readability, choose a format which is
already supported by numerous software.
The issue is that none of the other table formats I've seen are bothhuman readable and easily machine parsable. This one is.
In particular I think it's a bad idea to introduce something like this
as an optional recommended best practice. Either go all in, or what
looks like a table in one client will look nothing like a table in
another.
There are two issues with going 'all in' (which I understand as makingit a proper part of the gemtext part of the spec): firstly, that clientswill treat it as a must-have, which it isn't (it's pretty readablewithout any fancy rendering), and secondly that the spec is almostfinalized right now, and I don't see it making it in (because of howrarely it comes up). I did mention this as a best case scenario, butyour last point is why I've introduced this idea at all - to prevent theaggregation of multiple different supported table formats.
My suggested solution: if you really need an in-line human readable
table, lay it out in a preformatted block such that it makes sense to
a user with a client that interprets and displays preformatted blocks
as preformatted blocks. If you need the same data to be available
machine readable, link to a corresponding CSV/TSV/*SV below.
Well, with my format, you can have both. Of course, even slighly largetables can and should be kept in CSV or similar, but this works well forsmall tables which may be modified often. The issue with a fully laidout table in a preformatted block is 1) that it's getting intopresentation (different users will create different looking tables,adding style as they see fit, but that's against the general gemtextphilosophy), and 2) that it's difficult to modify cells without havingto adjust the entire table. My format is affected by neither, becauseall the table control is done via whitespace (and one can't style HTsand LFs), and because cells are on individual lines which are mucheasier to move around or to add to.
~aravk | ~nothien