Spacing problem in new public 1.3.7 version

Hello everyone, like mentioned here:

The new version brought some changes regarding spacing of heading, now I have A LOT of empty white space, before it was just perfect. Is this a bug or what? Honestly I wouldn’t like to use a snippet to fix this.

Does anyone know why this happen and if developers are aware of this? I would like to have it like it was before.


It’s not a bug. It’s an intentional change, I pointed to changelog.

I see this:

New CSS variables:

  • --p-spacing defines the spacing between >paragraphs (defaults to 1rem).
  • --heading-spacing defines the spacing >above a heading when it follows a paragraph (defaults to 2.5x paragraph spacing).

So I would need to create a snippet with different values right? Any suggestion on how to do it and what values to use?


Hi, the following is my snippet for tweaking these spacing issues. I hope it helps you somehow.
Best regards.


/* --p-spacing: 1rem; */
/* --heading-spacing: calc(var(--p-spacing) * 2.5); */

/* Change indentation of ul/ol; Remove spacing before an ul/ol */
ul, ol {
	padding-inline-start: 3.2% !important; /* var(--list-indent); */
	margin-block-start: 0px !important; /* var(--p-spacing); */
	/* margin-top: 0 !important; */
	/* padding-left: 3.2% !important; */
p {
	margin-bottom: 0px !important; /* For "remove spacing before an ul/ol" to work, this must be set */

/* Remove spacing above and below tables. This is done to remove the extra space between tables and headings */
table {
	margin-block-start: 0px !important;
	margin-block-end: 0px !important; /* var(--p-spacing); */
/* Only add spacing above tables when it follows a paragraph */
div:has( > :is(p,pre,table,ul,ol)) + div > :is(table) {
	margin-block-start: 1rem !important;

/* Change spacing above and below a heading */
h1, h2, h3, h4, h5, h6 {
  margin-block-start: 0.9rem !important; /* var(--p-spacing); */
  margin-block-end: 0.9rem !important; /* var(--p-spacing); */
/* Change spacing above a heading when it follows a paragraph */
div:has( > :is(p,pre,table,ul,ol)) + div > :is(h1,h2,h3,h4,h5,h6) {
	margin-top: 1.2rem !important; /* var(--heading-spacing); */

Is it possible to add a toggle in the appearance settings somewhere to restore the old functionality? It’s pretty distressing to have a whole vault of notes set up to appear exactly as I want them and then it gets messed up in a new setting that has no option to be turned off / restore prior functionality.

Adding the setting would be useless I think, there are already a lot of setting. Try using this snippet, which is a lot more simple than others already posted:

body {
    --heading-spacing: 1em;
    --p-spacing: 1rem;

Hope that helps

Note to developers: this kind of issue happened also with the 1.4 frontmatter, is not that we don’t want/like new features but many people spend much time creating a comfortable workflow/environment and pushing updates that does not bring any benefit but only require the user to fix things in order to revert to a prior state is not helpful.

I get that this “spacing update” was done in order to simplify the life of custom css developers, but you should have put as default settings something that resembled the prior. I also get that frontmatter update is to have a more clean yaml but lots of users does not want to see it on reading mode, and if on edit mode they just want a plain text.

And on a side note, why not focusing on the WSIWYG promised feature? I know we have live-preview but it’s not WSIWYG like Notion or Typora.


1 Like

On a related note, one way to avoid unending “Settings creep” would be to add a “snippet library” to Obsidian, where people could browse and search through categorized submitted snippets that do different things. I envision it as being similar to the Themes and Plugins galleries, where you can see a simple description, the css code, and an example of what it does.

This would greatly simplify the current “wild west” of snippets by giving people a place where they could easily discover and download some of the best customization ideas of the community. (It wouldn’t be the only source, of course; the ability to add your own manually would be unchanged.) And having easily discoverable customizations would reduce pressure on the Obsidian developers to add more and more appearance settings.