Closed wnm3 closed 1 year ago
Welcome @wnm3! 👋 Thanks for sharing your idea!
Our table implementation strictly follows GitHub Flavored Markdown (gfm), diverging from the standard, even as an option is a non-goal for the project. This could be filed with the gfm team at https://github.com/github/cmark-gfm or https://github.com/orgs/community/discussions, and once approved and merged into the GFM standard, we will match the standard.
Alternatively you could create your own parser extension to create the new table type, the process is rather involved, and it is not necessarily advisable to create yet another markdown favor. But it is an option. https://github.com/micromark/micromark#extending-markdown
Either of the above you could do yourself, or you could explore sponsoring a remark maintainer to do so on your behalf. I believe both @wooorm and @remcohaszing have done some consulting in the past.
Remark is a wrapper around lower level utilities like https://github.com/micromark/micromark (CommonMark implementation), https://github.com/micromark/micromark-extension-gfm (GFM implementation), and https://github.com/micromark/micromark-extension-mdx (MDX implementation). Designed to make it easier to work with the abstract syntax tree (more on that here: https://unifiedjs.com/learn/).
CommonMark (https://spec.commonmark.org/), GitHub flavored Markdown (https://github.github.com/gfm/), and MDX (https://github.com/mdx-js/specification) each follow a spec/standard. These existing plugins will not add features from outside their respective standards.
That said, you and others are welcome to looking into creating your own extension if wanted (guide: https://github.com/micromark/micromark#extending-markdown). Though know that creating yet another markdown flavor is both a complex endeavor technically, and would require training authors on the new standard.
Another possibility is reaching out to the standards groups themselves with the idea, and adding a feature to the standard. CommonMark has a standards discussion forum (https://talk.commonmark.org/), GitHub responses both to issues and discussions (https://github.com/github/cmark-gfm and https://github.com/orgs/community/discussions), and MDX has a discussion forum (https://github.com/orgs/mdx-js/discussions)
Your particular request is around tables, which is a part of the GFM standard.
Hi! This was closed. Team: If this was fixed, please add phase/solved
. Otherwise, please add one of the no/*
labels.
Initial checklist
Problem
I also host the OSS site (MDfromHTML) to convert HTML to Markdown. I’ve recently been working to improve table rendering from a bunch of HTML tables I’d put into a test page here. Some of these provide multiple header rows. I’ve supported this and Fletcher Penney’s MultiMarkdown Viewer supports this format as well. Note: for colspans and rowspans in HTML I elected to replicate the value so the table in HTML with multiple headers originally looked like this: I did this replication as one goal I have is to associate row and column headers with each cell…
Below is a screen shot of the markdown and rendering I’d hoped would occur:
Unfortunately, the plugin renders the multi-line headers by ignoring all but the last line (directly above the header separator line with pipes and hyphens):
Do you suppose you could add support for multi-row headers? Thank you in advance for your consideration. I will want to request the same for github’s markdown processing so if you know who I should contact please let me know. Thanks.
Solution
When encountering a table, read ahead to reach the header separator row (pipes, hyphens, spaces, colons...) then apply the alignment gleaned there to all rows above the separator to create the table header rows, then process the rows following the separator as table body rows.
Alternatives
It could be possible to consolidate all cells for multi-row headers by column using
<br>
or something, but this loses the boundary for explicit headers.