Plugins - Support tables on readme.txt files

[webdados]

While I understand the need to keep supported HTML to a minimum to avoid turning plugin listings into a carnival fair, I also see opportunities for improvement.

One example is tables, which are a great and accessible way to present organized data, such as, but not limited to, feature comparisons, and other tabular-like data.

AFAIK, this is not currently possible because we're using standard Markdown and not Markdown Extended / Markdown Extra, as @dd32 mentioned in Slack: https://wordpress.slack.com/archives/C02QB8GMM/p1775727510372729?thread_ts=1775725922.608499&cid=C02QB8GMM

[alexstandiford]

Seconding this! It would be very useful.

[bradvin]

+1

[jaz-on]

I'm in favour of experiments. Let's scope what markdown extensions from GFM, enhanced markdown, etc. would genuinely serve users, not just builders.

Tables (especially) are actually constraining data into structure, it does not add clutter imo. A formatted table is less annoying than the current workaround of scattered prose + external comparison pages.

I see a few things to discuss:

• Will these addition have cascading impacts on, let's say, the WordPress admin's plugin detail modal?
• Will it have translation and rendering implications?

Would it be possible to set limited experiments (maybe on a subset of readmes first) to demonstrate the value of such changes versus which ones just add complexity?

[webdados]

I can volunteer a plugin for testing. Actually, that's how I came to the conclusion that it was not possible.

[Bovelett]

I'm 100% supporting this, and it's a good moment to think about what "done well" looks like from an accessibility standpoint.
Tables are the right element for tabular data. When implemented correctly they are genuinely more accessible than the workarounds people reach for instead, such as ASCII-style layouts or lists with visual formatting trying to do a table's job.
The good news is that accessible table output is not complicated to implement. The parser just needs to produce the right HTML:

Header row cells rendered as <th>, not <td>
scope="col" on those header cells (or scope="row" if row headers ever get supported)
<thead> and <tbody> present, since screen readers use them for table navigation

The one gap Markdown table syntax cannot close is <caption>. Plugin authors will have no way to add a programmatic table title through Markdown alone. A small addition to the readme.txt format documentation, noting that authors should write a heading or introductory sentence before each table, would cover that in practice.

If the spec and the parser implementation move together, this is a clean win. Happy to help review from an accessibility angle if that's useful.

[webdados]

@Bovelett Thanks for the wonderful insight.