💾 Archived View for rawtext.club › ~sloum › geminilist › 004647.gmi captured on 2024-03-21 at 16:50:09. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Kiëd Llaentenn kiedtl at tilde.team
Sat Jan 2 04:52:45 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Sat Jan 2, 2021 at 4:36 AM UTC, makeworld wrote:
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 not
wrapping are required by the spec, and so are a non-issue. All the tables I've
seen are in preformatted blocks, and I would consider anyone not doing that to
be making a mistake, for the very reasons you've written above.
Yes, that's the point. If I have my client configured to use avariable-widthfont, I don't think I'd enjoy having just tables being in a monospacefont.
adding a new syntax to the spec
I doubt this will happen, gemtext is pretty set right now.
Just for the record, this was not what I was advocating.
And the ability to parse tables would go against its idea of clients only needing
to look at the first three characters.
Not necessarily. Something like scdoc's [0] table syntax [1] could beused:
=[ Foo=: Bar=:=| Row 1=: Hello=: world!=| Row 2=: Hello=: universe!
Unfortunately, such a solution means that the table syntax would beunreadable without further processing, which is also against the spiritof Gemtext(?)
Anyways. Back to ASCII art, I suppose.
[0]: https://git.sr.ht/~sircmpwn/scdoc[1]: See scdoc(5)
---kiedtl
"This, too, shall pass."