💾 Archived View for bbs.geminispace.org › s › Gemini › 17970 captured on 2024-06-19 at 22:52:32. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I have a question:
Is it an heresy to consider that the gemtext protocol would be incredibly better (like, a GIANT LEAP) with the inclusion of tables like in html2 (just the tables, i'm not mentioning anything else)? I think it would really help with the content organization in the space of the screen.
The developers had said much about gemini like an evolution of gopher, and it really is at protocol level but I really can`t say much about the gemtext standart, it's style... In the end, it feels almost the same as gopher, but with TLS issues.
Would that be possible to implement without a big difference in the performance, in theory? Or am I saying stupidity?
Jun 17 · 2 days ago
as the spec is nearing its final stages, new features like this won't make it in. I think others can chime in why, but it's likely due to presentation being left to the client.
Due to the complications of table cells being able to merge into multiple lines or columns for semantic reasons, I doubt it would be easy for tables to be added to the gemtext spec. The only "state" gemtext files can rely on a client understanding is whether a line is within a preformatted block or not. With a full table, it's likely a client would need to keep the state of how many columns and/or rows the table has along with possibly state of where/when to merge with other cells while building the table.
A useful feature of gemtext files is a client can parse it one line at a time and render immediately upon reading the line.
I think it would. But its ruins the simplicity of clients.
I am more bothered by the lack of underline or italics, which is an incredibly important typographic feature we are missing to identify titles of works or foreign text included within a passage. That one is hugely limiting.
A fourth level heading is another problem.
attach a jpeg for table, but image file is big. Or your could have a text block containing csv format, parse it in your head or paste the csv block to some external program. Latex table is more feature rich but much more complex. Is there a simple CLI program that would render csv text block? installing libreoffice just for parsing csv feels like a massive over kill.
something like this:
'''
test table,c1,c2,c3.c4
r1,1,2,3,4
r2,5,6,7,8
'''
of course, gemini client could opt to render the block. I mean lagrange already have the option to auto load image links in on gemini page.
I think the problem there is it isn’t human readable in any sense.
It’s like designing expecting image links to be expanded: doing that breaks the idea of a unified spec.
It’s like when Internet Explorer started adding crap to HTML that nothing else supported, leading to browser wars and sites designed to only work in a specific browser.
Ultimately, the only way to do it will be with preformatted blocks.
Best option may be a gemini project where you upload a CSV over titan (or use it as a CLI app) and it spits out preformatted text using Unicode to draw the tables.
good point, csv to preformatted conversion is easy to do, the conversion could be done in an editor. viewport size isn't a problem in gemini, so we can do away with client side rendering/padding. 80 char wide table is enough for many tasks.
☕️ tenno-seremel · Jun 18 at 06:55:
I think it would really help with the content organization in the space of the screen.
Tables for layout, yay! (nay) Users of smaller screens will be thrown under a bus the very moment it becomes a thing 😅
we already know that there is no consensus on table formats. How about just linking the csv/tsv file and let the browser figure out what to do, just like some gemini browsers already do for images and audio files. I think most browsers could probably implement unescaped TSV formatting
🕹️ skyjake [mod...] · Jun 18 at 12:46:
Having implemented a table layout routine or two in the past, it is way too complex for your average gemtext parser/renderer. As @vi points out, tables have a lot of nuance to them. In addition to merged cells, you'd probably want to control which cells are headings and maybe adjust the widths manually to make the layout more natural... It's a great deal of effort and the bang for the buck isn't really there.
I recommend either using preformatted tables like [1] and/or linking to some other table format (GitHub Markdown isn't too bad, for example [2]), and not worrying about the client presentation too much.
— [1]: Gemini Spacecraft On-Board Computer (OBC)
— [2]: GitHub Docs: Organizing information with tables
😺 Houjimmy [OP] · 11 hours ago:
Ok. But so let's start it simple: Using a library like "tabulate" within the preformated syntax ``` between a specific identifier would still present a very decent and easy tabulation, github-styled, at least for presenting text.