💾 Archived View for gemi.dev › gemini-mailing-list › 000597.gmi captured on 2023-12-28 at 15:49:47. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
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
"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/80f9 e9d3/attachment-0001.htm>
On Sat, 02 Jan 2021 22:35:36 +0100 nothien at uber.space wrote: > What do you think? I think that using preformatted blocks as an extension vector for table data is a bad idea. Preformatted then no longer always means preformatted. 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. 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. 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. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210103/4355 5c13/attachment.sig>
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 more interested in the actual format - but we can definitely change the containing 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 both human 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 making it a proper part of the gemtext part of the spec): firstly, that clients will treat it as a must-have, which it isn't (it's pretty readable without any fancy rendering), and secondly that the spec is almost finalized right now, and I don't see it making it in (because of how rarely it comes up). I did mention this as a best case scenario, but your last point is why I've introduced this idea at all - to prevent the aggregation 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 large tables can and should be kept in CSV or similar, but this works well for small tables which may be modified often. The issue with a fully laid out table in a preformatted block is 1) that it's getting into presentation (different users will create different looking tables, adding style as they see fit, but that's against the general gemtext philosophy), and 2) that it's difficult to modify cells without having to adjust the entire table. My format is affected by neither, because all the table control is done via whitespace (and one can't style HTs and LFs), and because cells are on individual lines which are much easier to move around or to add to. ~aravk | ~nothien
John Cowan <cowan at ccil.org> wrote: > "User" editors usually don't generate HT when the user presses the TAB > key. Sounds like an opinion, but then so is mine. I'm using (Neo)Vi(m), where whether HTs or spaces are inserted depends upon the format, but is easily changeable (:set [no]expandtab or :set [no]et). I don't actually know about many other editors. Do you have any data to back this up? I'll go looking myself as well, but if it turns out that HTs are uncommon then we may be able to replace them with 4 spaces (of course, that opens up the question of what happens when the number of spaces on a table line is not a multiple of 4, but we can figure that out). ~aravk | ~nothien
First of all, **Hello**, as it's my first message here. I like the original idea to some extent. It bothers me, that what is meant to be a row doesn't actually lay in one line. I immediately wanted to propose usage of TSVs as they are pretty human readable and have a good support in many text parsers. I don't want explicit support for tables, but rather making TSV inside a preformatted block a *best practice* for presenting data of tabular form. Fancy clients could have support for a technique of HT rendering known as [elastic tabstops](https://nickgravgaard.com/elastic-tabstops/) (tl;dr render tabs in blocks of neighboring lines to the same stop point, widening ones that are too short, if needed). But then simple terminal-based clients aiming to benefit from one-scan-to-render feature of text/gemini would suffer with all the usual problems we know from attempts to display TSV in the terminal. Example data (pure TSV): ``` Name Age Address Paul 23 1115 W Franklin Bessy the Cow 5 Big Farm Way Zeke 45 W Main St ``` Elastically rendered (using more tabs here, for illustration): ``` Name Age Address Paul 23 1115 W Franklin Bessy the Cow 5 Big Farm Way Zeke 45 W Main St ``` Solution could be to implement elastic tabstops in a greedy manner (align to the widest cell so-far). I think that greedy renderer is a good midpoint between naive aligning to nearest multiples of 4 (or 8 or whatever) and full elastic tabstops rendering. With this we could encourage users to make a table header containing cells of maximum needed length (for example by padding the remaining width with spaces). Obvious flaw of this solution is requiring text author to know the maximum widths of their columns (which can potentially be big raw data impossible to look up). But then TSV will look like table no matter what. Greedy/semi elastic render (without padded header) (`Name` column made wider after encountering Bessy the Cow cell): ``` Name Age Address Paul 23 1115 W Franklin Bessy the Cow 5 Big Farm Way Zeke 45 W Main St ``` Now that I think about it, this has little to nothing to do with spec (maybe I should send it to [tech] as well, or instead) as all of this can be put in best practices or even emerge as non-written standard for formulating/rendering documents. However, I think this is an interesting use of an uncommon text rendering technique to make plaintext capable of presenting tabular data. Let me know, what you think about that. Grzegorz Przybylski aka Zwatotem
Hello, nothien at uber.space writes: > 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 > ``` Well, I quite strongly oppose this idea. If your table like layout cannot be made with toggling preformatted lines useing ```, what's the point then? If you really need tables, maybe large tables, who is stopping the author from using xml, http, csv, or whatnot, and make it a downloadable file? >snip< > > What do you think? Don't do it. ~ew -- Keep it simple! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210103/a647 3247/attachment.sig>
"ew.gemini" <ew.gemini at nassur.net> wrote: > If your table like layout cannot be made with toggling preformatted > lines useing ```, what's the point then? I'm sorry, I don't understand what you mean by this. Also, I actually don't like the ```...``` layout I've used here, and I'm open to suggestions for replacing it. The primary concern to me is the actual table syntax. > If you really need tables, maybe large tables, who is stopping the > author from using xml, http, csv, or whatnot, and make it a > downloadable file? Well, yes, I agree. In fact, I said the same thing in my initial mail on this topic. But what about small tables? Yes, they can be done in a separate file, but that's often too much work for them - it's much easier to just do it inline. Especially when there are many of them. Having a separate file also makes it harder on users, particularly for those who don't have clients that do table inlining (e.g. gmnlm). ~aravk | ~nothien
> On Jan 3, 2021, at 21:09, nothien at uber.space wrote: > > But what about small tables? Yes, they can be done in a > separate file, but that's often too much work for them - it's much > easier to just do it inline. Use embedded data links: => data:text/csv;1997%2CFord%2CE350 Table Caption Ask you favorite client to render them inline. ? ???
I think having some, any, sort of table syntax that can be adjusted by the client is useful. Perhaps a balance between pre-formatted and attached could be something like ```parse:table +--------------------------------+-------+ | Food | Price | +--------------------------------+-------+ | Eggs | $2 | | Eggs and spam | $4 | | Just spam | $2 | +--------------------------------+-------+ ``` This way, clients don't *have* to parse it, but if supported, they can. Perhaps easier to parse would be. ```parse:table:/link/to/file.csv +--------------------------------+-------+ | Food | Price | +--------------------------------+-------+ | Eggs | $2 | | Eggs and spam | $4 | | Just spam | $2 | +--------------------------------+-------+ ``` This could again be optional and would allow for choice on whether content authors want their tables rendered and if clients support it. If the client doesn't support it, the table would show up as pre-formatted. The second approach would require more work by authors but the preformatted tables can be easily generated from a CSV (or any other format) by servers or static site generators. -- Karmanyaah Malhotra https://karmanyaah.malhotra.cc/contact/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210103/d333 56a6/attachment.sig>
Karmanyaah Malhotra <karmanyaahm at gmail.com> wrote: > I think having some, any, sort of table syntax that can be adjusted by > the client is useful. > Plenty of things would be useful. The question isn't "is it useful?" The question is "can we do without?" ```parse:table:/link/to/file.csv > +--------------------------------+-------+ > | Food | Price | > +--------------------------------+-------+ > | Eggs | $2 | > | Eggs and spam | $4 | > | Just spam | $2 | > +--------------------------------+-------+ > ``` > Ah, yes. Abusing the alt text. I've done that [1] and Solderpunk was not exactly amused. [2] Sure, use of alt text is at the client's discretion and the spec mentiones using it to indicate a programming language. Do keep in mind that it will be read out to visually impaired users, so please go easy on the syntax. For links, I recommend link lines. That way, everyone can get the file. Here is another example, with added line numbers to show intentional line breaks: 00] 01] ``` The table listing Food and Price says: Eggs are $2, Eggs and spam are $4, Just spam are $2. 02] +--------------------------------+-------+ 03] | Food | Price | 04] +--------------------------------+-------+ 05] | Eggs | $2 | 06] | Eggs and spam | $4 | 07] | Just spam | $2 | 08] +--------------------------------+-------+ 09] ``` 10] => /link/to/file.csv parse:table 11] > I put the link line on line 10 but you could put it on line 0 if you want. [1] gemini://gemi.dev/gemini-mailing-list/messages/000930.gmi [2] gemini://gemi.dev/gemini-mailing-list/messages/000933.gmi -- Katarina -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210104/b323 cd64/attachment.htm>
---