Help needed to make the new Markdown code for Table work

But are you sure that method meets the iNat code and will always work?

I can’t guarantee that. However, I’d like to point something out:

The feature announcement post here on iNat included this explanatory comment with two links:

We’re supporting most of basic Markdown formatting, plus the tables extension, even though we don’t have buttons for all those things.

Clicking that “tables extension” link brings you to a page which explains the syntax (worth reading) and includes this tip:

Tip: Creating tables with hyphens and pipes can be tedious. To speed up the process, try using the Markdown Tables Generator. Build a table using the graphical interface, and then copy the generated Markdown-formatted text into your file.

… so I’ll let you do the math on that question.

1 Like

Oh, thanks for pointing that out! As much of the info in the post was over my head I wasnt able to absorb it all. That’s a great help, now I can take down the flag in my head that says "…and there was something more in that post I need to follow up at some stage …:)

I have a great deal more confidence with the help I have had in this thread.

1 Like

Here is what was given for Table creation in the iNat feed on the new use of Markdown


So I am confused about what was meant by “a minimum of 3 hyphens”, and I still don’t a single, ie one place to go, source for the code which will be supported by iNat ongoing. @tiwane Could an update be issued for just this issue, of code that is and will supported in all areas of the iNat website, or even just the Journals, from now on??

are you taking this from here (

To add a table, use three or more hyphens ( --- ) to create each column’s header, and use pipes ( | ) to separate each column. You can optionally add pipes on either end of the table.

if so, i would note that it’s three hyhens per column, and i would also point you further up on that page, which states:

Not all Markdown applications support extended syntax elements. You’ll need to check whether or not the lightweight markup language your application is using supports the extended syntax elements you want to use. If it doesn’t, it may still be possible to enable extensions in your Markdown processor.

more in the context of this discussion, each implementation of markdown may interpret syntax for tables a little differently, which is why the forum handles column alignment, but the the main site doesn’t. in other words, i wouldn’t take the three-hyphen-per-column guidance as gospel. if you want to use 3 hyphens per column, then that’s fine. if you want to use more per column, that should work. if you want to use just one per column, that seems to work in this particular implementation.

No, from the News and Updates thread on this forum, which I understand is the official source of information on which code to use. I understand that what you have quoted is also a recommended source, but I have to verify some source before I pursue learning to use it (which has remained unsuccessful so far for including images in Journal posts), as I have spent far too many hours and days correcting work that is no longer usable as I used code recommended on this forum that worked at the time, but now does not.
I appreciate your help pisum, but I will need staff to weigh in here before I spend the next lot of time learning and implementing this excellent new feature.

Here is the News and Updates thread that advises us of the new protocol. It is weighed down with the more controversial Agree issue, unfortunately.

Like the blogpost that it links to

i don’t see “a minimum of 3 hyphens” anywhere in the blog post. could you point me to roughly where on the page you see it?

The blogpost links to
Which has this


To add a table, use three or more hyphens ( --- ) to create each column’s header, and use pipes ( | ) to separate each column. You can optionally add pipes on either end of the table.

| Syntax      | Description |
| ----------- | ----------- |
| Header      | Title       |
| Paragraph   | Text        |

okay. so we are talking about the same thing. see my above post where i note:


In that quote

delete this, our posts crossed

Exactly. SoI need to know what iNat supports. Bear in mind I dont understand all the terms used in these programming articles, eg “Markdown processor”…or Markdown Application…is that iNat?

Which conflicts with the example given in the blogpost of columns with only one hyphen each…
you can see why I am confused

1 Like

i think you’re looking for a 100% future-proof guarantee from the iNat staff that they can’t provide.

they are not writing their own code to interpret markdown. they are using code that others have written to interpret the markdown syntax. so it’s those other people who are deciding exactly how the markdown will be parsed / interpreted / processed / rendered / etc… (that other code is what i’m calling the parser, interpreter, etc.)

what makes the situation worse is that there is not a single standard in markdown to handle tables, as far as i can tell. for example, these are two different specifications for handling tables:

  1. GFM (Github Flavored Markdown):
  2. PHP Markdown:

… and different folks can write their parsers to handle to whichever specifications they like.

so if, at some point, iNat folks decide to use different parsers to handle the markdown, the new parsers may handle the markdown slightly differently than the original ones. or if markdown standards evolve, and the parsers change to handle the new standards, that may mean that old markdown syntax may no longer be supported in the updated parsers.

note that i’m using parsers (plural) above – because i think iNat uses different parsers in different places. you can already see how fragmented the situation is in iNat. take a look at this syntax for tables (which is just fine according to PHP Markdown but is not proper syntax according to GFM):


the forum interprets it just fine, a journal post in the main site interprets it just fine, but the observation detail page will not translate into a table. i think that’s because the journal page uses one parser and the observation page uses a different parser (because they are written using two different code architectures, i think).

complicating things further, if you add a markdown table to an observation (either in the description or in a comment), and then you look at it in the Android app, the app doesn’t show you a table at all (because the app code uses yet another parser, which i suppose doesn’t handle tables at all). if you pull it up in a browser on the phone, though, it looks fine (because the web on a computer is more or less the same as the web on the phone).

that said, i would suspect that as markdown standards evolve, the GFM syntax:


… will probably end up being the most well-supported (a de facto standard), if it doesn’t end up being the standard altogether (just because it’s so commonly used). so if you want the most future-proof markdown syntax, i think that’s it right there. (but, again, i doubt that anyone will guarantee that syntax to be 100% future-proof.)

however, i would suspect that most parsers of the future – and even now – will also support:


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.