Repository navigation
Plugins - Support tables on readme.txt files #600
Description
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
Activity
alexstandiford commentedon Apr 9, 2026
Seconding this! It would be very useful.
bradvin commentedon Apr 9, 2026
+1
jaz-on commentedon Apr 9, 2026
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:
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 commentedon Apr 9, 2026
I can volunteer a plugin for testing. Actually, that's how I came to the conclusion that it was not possible.
Bovelett commentedon Apr 10, 2026
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 navigationThe 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 commentedon Apr 10, 2026
@Bovelett Thanks for the wonderful insight.
webdados commentedon Jul 22, 2026
Anyone tackling this?
Who can decide to make this happen?
I'm not in favor of pinging @m for small stuff like this, as I would consider this micro-management, and I'm sure he has way more important stuff on his hands, but hey, I just did. (Sorry, Matt)