Allow tables without headers
See original GitHub issueSeems like there is support for allowing tables without headers (https://github.com/miyuchina/mistletoe/blob/master/mistletoe/block_token.py#L622) but it doesn’t seem to be allowed by parsing (https://github.com/miyuchina/mistletoe/blob/master/mistletoe/block_token.py#L661).
Would you consider allowing headerless tables? Perhaps something like the following would be a headerless-table?
--- | --- | ---
cell1 | cell2 | cell3
cell4 | cell5 | cell6
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Create a table without a header in Markdown - Stack Overflow
Most Markdown parsers don't support tables without headers. That means the separation line for headers is mandatory.
Read more >Accessibility Checkpoint - Data table without `th` headers
Data tables allow screen reader users to understand column and row relationships. ... If a data table has no headers, add th elements...
Read more >No header tables - FooTable - GitHub Pages
Simply make sure the first tr in your table contains only td cells and supply the column option attributes on them. If a...
Read more >Tables with Irregular Headers | Web Accessibility Initiative (WAI)
This page covers tables with header cells that span multiple columns and/or rows. Several elements and attributes can be used to define the...
Read more >No header row specified | Accessibility - Social Security
To check row headers in data tables: Inspect the table headers and data to determine if row headers have been employed in the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@anderskaplan, thanks for the analysis!
As there doesn’t seem to be enough drive / votes from the mistletoe community to support the requested feature, I would also vote for just cleaning up the code and be GFM-compliant, i.e. NOT to support headerless tables, at least for now.
The current state of the table parsing code is indeed ambiguous, and the docstring describing the Table token is misleading. It looks like there are remnants from an older version of the code, and it would be nice to get this fixed. I’d be happy to take a stab at it, but then I’ll need a bit of direction: do we want support for headerless tables or not? And if yes, to what extent?
The simple example above where the header and separator lines are just omitted is simple enough, however, the table spec from Kramdown is quite extensive and adds not only headerless tables, but also makes start and end pipe characters optional, introduces additional separator lines, etc. So adhering to the Kramdown table spec would be quite a bit of work and I don’t really see the point of it.
My suggestion would be to let tables adhere to the GFM spec and NOT support headerless tables – but to remove the ambiguity in code and comments. (In the same spirit, I’d also suggest to implement #131, but that’s a separate topic.)
Or, as a second option, to implement support for headerless tables like the one in the simple example above.
Thoughts?