Parsing of table after heading (with/without blank line)

Bug graveyard
, , ,
1

Steps to reproduce

Add a table directly below a heading:

## Heading
| | |
|-|-|
|Day|Week|Month|

That table no longer renders correctly in live preview, but does render correctly in reading mode. If you add a blank line directly after the heading, it starts rendering correctly.

Expected result

A correctly-rendered table, in live preview mode.

Actual result

No table is rendered

Environment

SYSTEM INFO:
	Obsidian version: v1.3.4
	Installer version: v1.3.4
	Operating system: Darwin Kernel Version 22.5.0: Mon Apr 24 20:52:24 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6000 22.5.0
	Login status: logged in
	Catalyst license: vip
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: light
	Community theme: Solarized v1.0.5-beta
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 1
	Plugins enabled: 1
		1: Advanced URI v1.35.0

Additional information

I tested on the sandbox vault as well, same result.

5 Likes
2
1 Like
3

thanks

4

Could you elaborate on why this is considered a bug when this is not?

5

we haven’t decided if we wanna allow a table right after a heading (the reader does it) or require a blank line in this case as well.

1 Like
6

Yeah I’m open to this being intended behavior. But it was a regression for me, a bunch of pages broke. :man_shrugging:

Edit: I think the reader view should match, in any case.

2 Likes
7

Personally I really prefer having headings immediately followed by a table. Adding the extra space creates too much dead space in my opinion.

I’m fine with having the space be required otherwise, as it keeps tables separate from other data. But the header is already a natural separator, so I think the previous behavior is preferred.

4 Likes
8

Agreed. The dead space is certainly uglier.

2 Likes
9

Add me to the list of people who are vehemently against this change (or start one, I guess? I do feel pretty strongly about it); it’s broken just about every single table I have, and I use them often, including in my daily note template. Vertical space is at a premium on modern monitors, and I’ve spent far too much time and energy setting up things to look and present info in an efficient way to start adding blank lines everywhere.

As for the argument that this is how Markdown is supposed to be (I saw that on the closed topic that was linked above), aren’t there other settings that directly conflict with Markdown’s “true” implementation? I can think of the “strict line breaks” setting off the top of my head

Really hoping that this is reconsidered.

3 Likes
10

Let me reiterate that the change introduced was to align LP to the reader parser and to other implmenentations. We didn’t break things with this update, things were already broken. Perhaps, you didn’t notice because you don’t use reader/export to pdf/canvas/publish.

This issue tracked in this BR is specifically for the behavior after headings.

1 Like
11

I am just confused because a table directly under a heading works in reader mode but doesn’t in LP. But I thought the change was made to align the two modes? Anyway, I personally prefer having tables under headings and even if a new line will be required going into the future, I believe there should be consistency between the modes.

12

You’re 100% correct, I don’t really use Reader mode. That said, to be totally fair, I don’t think that would change my opinion… Like the other commenter mentioned, this doesn’t seem like it actually does align Live Preview with the Reader functionality. Before this change, both Live Preview and Reader modes showed a table under a heading without an empty line between the heading and table. Now Live Preview does not, while Reader mode does.

13

My point was that Live preview and reader had bigger differences before. Now the remaining difference, with respect to tables, is with headings, hence this bug report to track the specific issue.

1 Like
14

ok, so the end goal is that the Reader view also begins to not show tables in this instance?

15

Read this thread again.

1 Like
16

real friendly atmosphere here, yeah? I’m trying to be polite, man…

Where do I go to add my name to a list of people who disagree with these changes? I’m clearly not alone, based on my searching around in the last few days.

1 Like
17

I also disagree with these changes. The dead space is ugly and it breaks all the tables that I already have.

I have tested with other markdown editors online (including how Github parses markdown), and they all allow the behavior having a text precede a table

1 Like
18

You can use this in a css snipet to hide some of whitespace, adjust the numbers until it feels right to you.

.markdown-rendered table {
  margin-block-start: 0;
}

.cm-line:has(br) { /* Optional but gets rid of some more of the whitespace */
  height: 1em;
}
1 Like
19

I am also frustrated with this change that breaks a large quantity of my notes as usually have a table directly after a heading. The CommonMark spec doesn’t require spaces after headings.

1 Like
20

Example 78 that you linked is a about a paragraph of text after a heading. And that works.

You won’t find examples of tables after headings in the commonmark spec page because there are no tables in commomark (at least not yet). Commonmark hasn’t ratified a specification about tables at all. There’s a lot of fragmentation in the space around tables.