~araspik

I'm not sure that tables have ever worked. I don't think we've ever supported that extension, and I've always written them in inline HTML.

They used to render pretty nicely in both firefox and qutebrowser. But if this is not officially supported I can just change the readme. Is there some documentation about what parts of Markdown/extensions are supported?

We're using mistletoe, which is supposed to support CommonMark, and we've only added plain links on top of that. Nothing else is supported, at least at this moment. From the looks of it, CommonMark doesn't support tables, so even the current state is just mistletoe being nice.

For now, I guess, use inline HTML for tables containing images (but this issue should stay open until we actually decide on the feature). I'll check mistletoe code tomorrow, see exactly what level of support is provided for tables. I suspect there's a parsing precedence issue somewhere resulting in images overriding the table from being parsed properly. I may end up submitting a ticket for mistletoe and implementing a fixup on our end (we can override mistletoe functionality in our Renderer class).

I think we might be wise to draw the line at standardized features. Perhaps the first step towards adding a table extension would be to write a commonmark standard extension for it?

There's a possibly relevant bug: https://github.com/miyuchina/mistletoe/issues/60. It's about the parser not dealing properly with tables without headings (it could be why the other tables in the README worked?).

I don't understand what you mean by 'commonmark standard extension', but I'm guessing you're talking about clearly defining how tables would work. There's some general consensus among Markdown parsers about this, I'll see what I can find tomorrow.

P.S: My development environment is completely broken at the moment, so I may not be able to make/send patches immediately.

Right now, if someone asks what Markdown rules sr.ht uses, there's a standard we can point to. And if sr.ht's behavior does not match that standard, sr.ht can be corrected. This is desirable. If we add extensions without standardizing them, then (1) others can't create compatible implementations and (2) our implementation is poorly understood.

Okay, that makes sense. From the discussions I've seen (i.e. this one), tables are a difficult feature to get right. The most common format is pipe tables:

| Header 1 | Header 2 |
|----------|----------|
| Text 1   | Text 2   |

There are many related extensions adding support for things like column alignment, but this is the basic idea. See the linked discussion for some pros/cons.

We can support multiple table formats. I think we should support pipe tables initially, and add more stuff as we move forward.

P.S: It was weirdly difficult to find the Markdown page for sr.ht. Could we make it more widespread somehow? (e.g. putting "markdown supported", which links to the page, below or near text boxes supporting markdown).

~araspik

It was weirdly difficult to find the Markdown page for sr.ht. Could we make it more widespread somehow? (e.g. putting "markdown supported", which links to the page, below or near text boxes supporting markdown).

Agreed 100% on making the supported Markdown elements more discoverable. I still don't know where it is :D Adding it to the git.sr.ht docs would also be nice.

https://man.sr.ht/markdown

WONT_FIX/NOT_OUR_BUG

We're using CommonMark now, and even if we fixed this, it'd apply to markdown across all sites and belongs on ~sircmpwn/sr.ht.