What were you doing: Adding text to an established table design (in a template)
What feature did you use: Table
What happened: The table contents no longer respect the page’s content area
What did you expect to happen: Previous to 3.0 adding content to a cell with enough text to word wrap would equalize the space used by columns with “wrapping” cells in them, keeping the entire table contents visible without horizontal scrolling.
Before adding content to the Answer column in 3.0 (the table is at 100% of the page width)…
Expected: Well I can’t show you because I can’t downgrade back to 2.x but as I would type in the Answer column, the Question column would shrink until the Answer and Question columns had the same widths and the entire table would be visible without horizontal scrolling.
I get why this new behavior might have been a feature request from some but I didn’t see this in the release notes so I’m logging it as a bug. I use these notes during a live podcast recording and having to constantly scroll left and right would be a dealbreaker for me.
Yes, this was changed some weeks ago with the 2.9.4 update, if I’m not mistaken. We have changed the minimum and maximum table cell widths based on user feedback. I’m registering yours as feedback in the opposite sense, but I wonder if modifying the line width in Bear’s preferences changes something for your use case.
Ugh. Well i understand reasons why one would want one system or the other but if this is the only way it works then I’ll have to cancel. I can’t fuss with settings in real time.
Totally agree with this - a scrollbar making the table effectively infinite width with no ability to fix the column width is horrible. It effectively breaks printing, it makes use on a small screen a pain where you don’t want to be scrolling. I’m a relatively recent adopter but I’m struggling to see how what came before could have been worse than this?
I totally get that Bear isn’t and shouldn’t be Word or Excel but it feels that fixing column widths and wrapping text should be feasible?
I also noticed this issue with the latest update. After stumbling across a Reddit thread of someone having the same issue, I tried adjusting the line width, but this has a negative effect on bullet lists – the line length is too wide to be easy to read. It would be nice to have an option to go back to the previous behavior.
I’m experiencing the same issue. Even on a simple 3-column table, a horizontal scrollbar shows up, meaning I can no longer view the whole table at once like before.
I would also like to register a request to either restore the previous behavior, or provide a persistent option to configure the old behavior. While I appreciate the responsiveness to requests for the change made in 2.9.4, precedence does matter here. There are many folks who count on the previous behavior who have to now adapt to an unwanted change.
First I think wide markdown blocks, like tables shouldn’t be constrained to body text column width. They should be wider without requiring the user to have to set a suboptimal line length for body text elements work around the issue.
Also the micro typography could be adjusted. The font size should be smaller than body copy with a adequate adjustment in line height. Ideally a condensed version of the default typeface and if available a condensed version of the custom typeface set by the user.
Neither of those features would help with what people are asking for here. As soon as the text in the last column cell would (formerly) word wrap in the cell, the table bounces to this wider iframe-like width. Smaller fonts and line width don’t help assuming one has more than a minimal amount of text per cell.
I doubt there’s a single solution to this to satisfy both fixed-width and wide-width users. It would probably have to be a toggle which I don’t know if the devs would go for – Bear seems like a pretty ‘opinionated’ app.
Personally I built my own bespoke solution with the table design I need so I don’t have a dog in this hunt anymore but I thought I’d mention compacting font widths and line heights doesn’t address the issue.
It addresses the iframe-like part of the issue but because I have table cells with a decent amount of content in them, it’s squishing the last column narrow enough that with all the content in the cell, it’s making the row unusably tall.
