💾 Archived View for rawtext.club › ~sloum › geminilist › 004646.gmi captured on 2024-03-21 at 16:50:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
colecmac at protonmail.com colecmac at protonmail.com
Sat Jan 2 04:36:06 GMT 2021
- - - - - - - - - - - - - - - - - - -
1. It requires the client to display the table in a monospaced font,
which many would prefer not to use.
2. Text in table rows won't be wrapped properly on narrow displays.
If you put your table in a preformatted block, then a monospaced font and notwrapping are required by the spec, and so are a non-issue. All the tables I'veseen are in preformatted blocks, and I would consider anyone not doing that tobe making a mistake, for the very reasons you've written above.
3. ASCII tables are anything but screenreader friendly, since there's no
semantic information about the table's structure.
Yes, that's the main problem in my opinion. I don't see a great solution really.Perhaps if the word table is in the alt text (an unofficial idea, which is thetext right after the first backtick line), a really good client could interpretwhere the cells are and read them? It would be error-prone of course, and stillnot very accessible.
4. It mixes information and presentation, which is against the spirit of
Gemini(?)
The point of preformatted blocks is to control presentation in the specificcases where it's needed, like code, ASCII art, or I guess tables. While ingeneral you're right, I think there is sort of a "precedent" for this mixing.
So, are there any other options for having tables in Gemtext
You could create a CSV or HTML file and link to it? Other than that I'm not sure,I don't see an easy solution to this.
adding a new syntax to the spec
I doubt this will happen, gemtext is pretty set right now. And the ability toparse tables would go against its idea of clients only needing to look at thefirst three characters.
Cheers,makeworld