If I were to pick a mis-feature that prevents Obsidian from becoming a foundation of a solid documentation system, I would say “tables” without hesitation. I use Obsidian for work (with a commercial license), but tables are so painful that I cannot in good faith recommend Obsidian to my colleagues for use cases such as technical documentation or “industrial strength” note taking.
This post is not a classic feature request, it’s more an invitation to explore the problem and possible solutions. The limitations have been discussed many times (1, 2, 3, 4), but I thought I could give it a more thorough treatment.
Markdown aspect
As we all know, pure Markdown tables are only good for trivial tables. Biggest limitations:
- They only support one line of markdown per cell.
- They don’t support merged cells.
The typical workaround is resorting to HTML:
-
While still using Markdown table syntax, one can do multi-line cells by using
<br>inside the cell. Lists can be simulated using ad-hoc bullets. Drawbacks: only one level of indentation is realistically possible; merging cells is still unattainable. - An even more radical approach is using HTML for the entirety of the table. Since HTML is valid markdown, it’s possible to create fully advanced tables.
The workarounds don’t work very well with Obsidian, as I’ll describe below.
Obsidian aspect
Obsidian’s current implementation exacerbates the limitations of Markdown tables.
- Issue 1: editing the table currently involves editing its direct Markdown source. This is OK for very simple Markdown tables. But the usability of this approach goes to zero rapidly as the tables become more involved. Creating or editing tables that contain HTML (or even cells with more than a few words of plain text) is extremely hard. Each table row is represented as a long line of HTML/markdown soup, and requires horizontal scrolling to navigate.
- Issue 2: in Obsidian, Markdown ceases to be parsed inside HTML tags. One can resort to using HTML for formatting, but there’s no replacement for lost internal links or wikilinks. This prevents using fully-HTML tables in Obsidian.
This situation brought about a whole “market” of table-related plugins that try to improve the situation in their own way. However, compared to the table experience of any WYSIWY[MG] text editor, they are all clunky. They inevitably require more steps than just “edit the table”: add a code block with non-markdown (Asciidoc Blocks plugin), or open a separate window (Markdown table editor), or define the table in a separate file (Notion-like tables).
The best such plugin that I’ve come across is Table enhancer (which isn’t in the Obsidian plugin store). But it shares the common flaw with the other plugins: it trips and falls when the table has a <br> or does something slightly funky. So, plugins don’t really solve the problem.
Keep in mind that creating new tables is only one use case, and a determined individual can tolerate some tinkering in order to make an odd table. But another important use case is capturing content from other sources. Advanced tables are abundant on the Internet, docs, etc, so the inability of Obsidian to take that information in is not good.
What can be done about it
I know it’s easier said and done. But I see no alternative to implementing a WYSIWY[MG] table editing experience, if Obsidian wants to compete with OneNote, Notion etc. And I feel this feature should be be sufficiently “core” to not delegate it to a plug-in.
As an idea: to make sure that full Markdown compatibility is retained, and the biggest table limitations are lifted, this editing feature could treat the Markdown table contents in a slightly special way. Obsidian already supports <br> tags inside tables by rendering them as newlines. However, Obsidian could start to treat <br> as \n when interpreting the markdown inside a table cell. This way, Obsidian could begin to render multi-line markdown features such as paragraphs or multi-level lists inside table cells. This interpretation would be internal to Obsidian, and would not preclude the emitted markdown tables from being valid and properly displayable by other markdown software. This wouldn’t immediately solve the cell merging limitation, but it feels like the biggest leap forward with the least added complexity.
Thanks for reading this far. Feel free to correct anything that I got wrong.