Comment by 🚀 SavaRocks
Re: "How should I do tables in gemtext for my blog?"
for http it's good practice to format the tables into <pre> and <code> as it's gonna use a monospace font and the table will look the same
Mar 19 · 7 weeks ago
19 Later Comments ↓
🌆 skyjake [mod...] · Mar 19 at 08:39:
@lars_the_bear:
people would use it for doing page layout. That's exactly what happened to HTML and, in my view, marks the start of its decline into today's chaos.
Yes, that is one part of the slippery slope, while the other is feature creep: if we justify adding a feature for one use case, what's stopping us from accommodating some other use case down the line? Gemini is purposefully not meant to evolve with new features over time.
It's best to recognize gemtext has limits. Content that does not work within those limits should use some other format. For example, linking to a PDF file containing a big/complex table is a reasonable solution.
❤️ fairlygood · Mar 19 at 12:36:
Our definition of reasonable is very different. Haha.
I do think that Gemtext is a little too bare bones, but I understand the whys and what not.
I use a library called asciitable to make this easy in my Scriptonite software. It's in Java but I'm sure there are equivalents elsewhere.
🏍️ Atomic-Germ · Mar 19 at 18:07:
If you're making a table to display a table, yes this method works. And otherwise, think of gemtext as txt.
And if you want your tables to be 'useful', have a look at CSV files. They feel quite gemini.
Here's how it sounds on a mac
🐑 zipsegv [OP] · Mar 21 at 03:47:
regarding adding features to gemtext, I agree that we shouldn't. However, there's no reason we couldn't serve commonmark over gemini or something; there just needs to be more browser support for it.
🚀 lars_the_bear · Mar 21 at 08:24:
@zipsegv : In principle, I'd support that proposal, and I'd even be willing to write/add the code to do it.
Problem is, unless _all_ clients can do it, we'll end up in a situation where authors have to provide multiple versions of the same post, to suit the different browsers.
❤️ fairlygood · Mar 21 at 10:01:
Is there any practical reason as to why clients cannot render markdown elements like tables, or even implement basic page customisation (maybe through yaml headers, or a subset of css). I know people feel strongly that they shouldn’t - but that’s different from can’t.
🌆 skyjake [mod...] · Mar 21 at 10:20:
The practical reason is that there is no specification for such things. This means if one client makes up their ad hoc spec/implementation, there is little hope of anyone else implementing the same. I doubt people would bother with client-specific special cases for publishing their content.
❤️ fairlygood · Mar 21 at 10:36:
Perhaps. I know I’m in the minority, but I would love to see some additions to the gemtext specification.
🚀 lars_the_bear · Mar 21 at 13:55:
Personally, I'd be happy with additions to the specification that comply with the spirit of Gemini. In my view, allowing for a richer document format probably would, but allowing clients to visually style their documents probably wouldn't. It's a difficult line to draw, between what's acceptable and what isn't.
I can’t follow the argument that implementing tables would spell the end of Gemini. HTML works very differently and allows elements to be nested. That is not the case in Gemtext, tables are just tables and cannot be used to construct layouts. And lists are simply lists. There is no way to mix them with links.
❤️ fairlygood · Mar 21 at 21:46:
Or, god forbid, some sort of emphasis.
🚀 lars_the_bear · Mar 22 at 08:11:
Even emphasis isn't straightfoward. Suppose we allow markup like '*bold*' . What do we do if we want to use the '*' character for something else? There need to be rigorous standards for when these markup characters have their special meanings, and how to override them when that meaning shouldn't apply.
And if you allow multiple forms of markup for emphasis -- say bold and underline -- they we need to decide whether they can be nested and, if so, what the effect should be.
These things haven't been completely settled in the Markdown world, even now. It all looks straightforward enough but the Devil, as always, is in the details.
Not disagreeing, but this needs careful thought.
CSV really should be a supported format for preformatted lines. Markdown's way of doing tables seems the wrong way.
🚀 lars_the_bear · Apr 19 at 08:41:
@arma : I can certainly see why you might think that. But Markdown tables (which I don't think are fully standardized) are designed to be human-readable as plain text. That is, you should still be able to visualize the tablular format even if the Markdown isn't rendered. That isn't really true with CSV, and you still need a way to signal whether there's a header row or not.
@lars_the_bear Markdown's extended syntax does support tables. That sort of graphical thing isn't something I'd ever want to write manually. About detecting whether CSV has a header row: the fact that there's not a definite answer to that is an intrinsic shortcoming of CSV. I'd say CSV doesn't really support headers, but many act as if it did. So, for now now I'd say CSV contained in preformatted lines is the best option. As for detecting header rows, I'd say the same heuristics that are in use today apply here as well. Another option would be to create an alternative to CSV that mandates a header, or has an option to indicate whether there is a header.
🐑 zipsegv [OP] · Apr 25 at 05:54:
@arma:
That sort of graphical thing isn't something I'd ever want to write manually.
this seems more like an editor issue than anything. For vim there's table-mode[1] which is extremely useful, and I imagine something similar exists for other editors.
Original Post
How should I do tables in gemtext for my blog? — I have a blog (that I've been meaning to write to more). I use an SSG to generate both html and gemtext from a custom format, and I've recently needed to have tables for a post I want to make. However, gemtext (obviously) does not have tables. My idea was to use preformatted blocks to draw a diagram of this, so something like this: [preformatted] However, I'm not sure if this is good from an acessibility point of view. Does this cope well with...