Tables could be exciting

There are not many note-taking apps that do tables well. Can Bear App seize this opportunity and create an awesome table UI?

The value of raw data and raw observations is increasing. Bear doesn’t need to excel at AI hype or data analysis, but it does need to excel at information capture. It would be great if I could input structured information more effectively.

First, most issues with the current table implementation are fairly obvious. Here’s a short list:

  • Lack of multi-cell selection
  • No obvious UI for adding rows/columns.
  • The style toolbar should probably expand with table-specific actions when a table is selected
  • Table width should be allowed to exceed the content area
  • Lack of header cell types
  • No sticky header cells
  • Cells can’t contain attachments or photos
  • Cells can’t contain bullet points or ordered lists
  • Row or cell reordering is not supported (supported by shortcut or context menu, nevertheless I can’t select multiple rows and copy/paste them to different locations)
  • Inconsistent context menu behaviors. There are three scenarios: (1) right-click on the active cell, (2) right-click on a non-active cell—this selects the whole table and gives a menu for the entire table, but lacks table-specific items like CSV export, and (3) right-click on the three dots beside a cell, which provides both cell and table options like CSV export.

Second, tables could benefit from something similar to the “Quick Preview” feature available with attachments. This could be an extended table UI or even just packaging an inline table as a CSV file and opening it in the native macOS Quick Preview window on the fly.

Third, I think better support for table file attachments would be excellent. CSV, TSV, Parquet, etc., where tables could be displayed inline like PDFs, with simple table controls like show/hide/reorder columns. This would enable people to add tabular data directly into their notes. Even better would be a way to create structured data natively within Bear.

Better table functionality would help Bear capitalize on the growing value of raw data and attract data-minded users.

7 Likes

This is a great list! In its current state, the UX around tables is woefully bad.
I really hope to see some improvements in the near future.
I know you say tables are limited due to markdown compatibility issues, but even just better selection options or some nice-feeling buttons to add new columns/rows would make a huge difference IMO.

2 Likes

I, too, lament the state of tables in Bear. However, I also recognize the primary goal of the Bear development team is Markdown compatibility. I appreciate that North Star, as it would be all too easy for the app to become bogged down with bells and whistles until it became another Word wannabe, which is not what any of us wants.

Is there a Markdown extension that supports enhanced table capabilities that wouldn’t detract from the main Bear focus? If so, bring it on, along with all the other features I’d love to have. But, as it is, Bear is an exciting enough application. UX could be improved, but not at the expense of underlying integrity of the data model, please.

I’d only want one thing: tables should adapt to the current width of the note.

I just tried out Apple’s AI and it flawlessly converted a list into a two column table (!)

Shhh :shushing_face: … don’t say “markdown compatibility”, it’s too emotional for developers. We can say instead “clever use of markdown”.

Unless of course you say that Bear App is the one breaking compatibility. Which may be the case here. The pipe delimited syntax for markdown is not in the original standard but defined in Github Flavored Markdown (GFM) as an extension to the original syntax. The original syntax suggests using the <table>... block element syntax. GFM also reaffirms the use of this syntax and the example given in its documentation is a table.

I’ve tested VS Code, GitHub, Obsidian and Trello. All except Trello support and render table block element syntax. Trello doesn’t support any tables, so it doesn’t even render pipe delimited syntax. Bear App is the only other markdown engine that I see that doesn’t support this syntax.

“But Bear App doesn’t support any block element syntax” you might say… Is there any discussion on this as to why? I haven’t found anything in the community forum as to why block elements are generally not supported. I’m sympathetic – it’s messy duplicate syntax and it is probably the right decision. But when needed it should be used… there is already a current exception for <br> inside of tables.

All of that aside, I just want to put a nail in the coffin of “markdown compatibility” and focus the discussion on what tables and their UX could be.

Avoiding being a “Word wannabe” is very valid – but I think if the focus for UX was on data aspects input and display rather than style then we steer clear of that.

Just wanted to clarify a few things, because I think there’s a bit of confusion here between Markdown and HTML.

First, saying that the <table> HTML block is “suggested by the original syntax” isn’t quite accurate; the original Markdown spec (by John Gruber) explicitly treats raw HTML as a passthrough, not as a first-class Markdown feature. It doesn’t “suggest” <table>, it just allows raw HTML to go through unescaped, assuming the renderer can handle it.

Bear doesn’t support HTML by design and that’s intentional, not a limitation. Our goal is to render Markdown, not a hybrid of Markdown and HTML. That means we don’t render block-level HTML elements like <table>, <div>, or <span> inside the editor. We still highlight them for readability, and they’ll work if you export to HTML, but they’re not rendered in-app.

Bear is a native app with a custom Markdown renderer, not a browser-based editor wrapped in a web view. That’s a key distinction, and it’s part of what makes the experience lightweight, fast, and focused.

I’ve tested VS Code, GitHub, Obsidian and Trello. All except Trello support and render table block element syntax

Just to clarify: no Markdown editor actually supports <table> as part of the Markdown syntax. If you see it working somewhere, it’s because that app passes raw HTML through and relies on a browser engine (like Chromium or WebKit) to render it in previews or exports.

So what you’re seeing isn’t the Markdown engine supporting <table>, it’s just HTML being rendered on top of the Markdown. That’s fine if your goal is HTML export, but it’s fundamentally outside the scope of Markdown itself.

Bear deliberately doesn’t follow that approach because we aim to render Markdown, not arbitrary embedded HTML which keeps the experience consistent, predictable, and more portable across platforms.

8 Likes

To be fair, I have to say that many, if not the very most points the OP mentioned are improvements that wouldn‘t touch markdown compatibility at all.

2 Likes