Paragraph breaks not preserved in Preview mode

[Duhkha]

Things I have tried

Forcing line breaks with three spaces or <br> syntax to mimic a paragraph break.

What I’m trying to do

Have edit and preview mode paragraph breaks/views be consistent. Regardless of theme, workarounds, etc. unexpected behavior persists.

I want:
Paragraph 1 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content.

Paragraph 2 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content.

What I see:
Paragraph 1 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content.
Paragraph 2 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content.

Adding <br> in the line between simply creates a second line break, so it’s no longer a true paragraph break.

I’m generally aware of how html (and, therefore, .md) parses line/paragraph breaks, but Drafts and another text editor parse above as desired in preview mode.

Thoughts? Thanks.

[anon12638239]

Are you using two returns after each paragraph?

Angel

[Duhkha]

Of course. Thanks.

Paragraph 1 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content. (RETURN 1)
(RETURN 2)
Paragraph 2 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content.

[Duhkha]

@anon12638239 Regarding my <br> reference in my initial post, I based this on line break references here:

Basic Syntax | Markdown Guide

This is different than <br />, which does render a paragraph break in Preview mode if between two paragraphs. But visually, the Preview formatting is the equivalent of two line breaks between the paragraphs (three total—one after first paragraph, two between the paragraphs themselves):

vs. what I want:

Paragraph 1 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content.

Paragraph 2 of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content Paragraph of riveting content.

I simply want to learn and I’ve never had difficulty previewing this properly in other text editors. Thanks.

[anon12638239]

This is how I understand things. Other people might have better answers.

In HTML, <p> defines a paragraph break (which is a break between two blocks of text), and <br> defines a line break (which is a break inside a single block of text).

In Markdown, a ‘paragraph is simply one or more consecutive lines of text, separated by one or more blank lines.’

To create a line break in Markdown, ‘you end a line with two or more spaces, then type return.’

I use two returns (creating a blank line) to form paragraphs. I only use line breaks for things like poetry or addresses, where paragraph breaks would be too wide.

As to the difference between <br> and <br />, my understanding is that <br /> is a stricter enforcement of HTML rules. In most cases / editors, the two forms are interchangeable.

I found this reference useful.

Hope this helps. Source text below if you want to see this note live.

Angel

source3.zip (1.9 KB)

[Duhkha]

@anon12638239,

I appreaciate your help and patience. I am familiar with the syntax you referenced and trying that and other workarounds remains unsuccessful.

Perhaps I have a corrupt preference file. I use the Minimal theme, sliding panes, and a number of other plugins.

I wrote this in Obsidian’s Sandbox Help vault. Please read for a play-by-play of my efforts.

Here’s the exact same content in my vault using Minimal theme (sliding panes disabled). Notice how paragraph formatting is not preserved.

So, line breaks work as intended. Paragraph breaks do not with my current vault configuration but they do with the Obsidian Help vault.

Thoughts? Grateful,

-John

[CawlinTeffid]

Have you looked thru the settings for your theme for anything that might be relevant (related to paragraphs, line spacing, margins, etc.)?

[efemkay]

i think the para <p> may not have margin somehow.

while using obsidian, press CTRL-SHIFT-I (option-cmd-i for mac) to bring up the developer window. use the pointer (in red box below) and select on any of the paragraph. look at the box model there (in the picture, the one with margin, border and padding).

if u dont see any margin, like some css snippet make it so.

Getting comfortable with Obsidian CSS - Share & showcase - Obsidian Forum

[anon12638239]

I agree with @CawlinTeffid and @efemkay in that I think the theme is impacting on the styling in the Minimal screenshot.

Two additional points:

1. Regarding line breaks as in your example:

The spaces syntax is highly variable for me SPACE, SPACE (see, no line break) and rarely seems necessary unless you truly need to force line break.

SPACE SPACE does not create a line break in Markdown.

SPACE SPACE RETURN creates a line break within a block of text.

From Gruber’s syntax guide:

When you do want to insert a break tag using Markdown, you end a line with two or more spaces, then type return.

2. Under Settings → Editor there is the following option:

Strict line breaks
Markdown specs ignore single line breaks in reading view. Turn this off to make single line breaks visible.

If you have that setting toggled off, single RETURNS will show in live-preview mode and in reading mode as line breaks.

If you have that setting toggled off, the poetry lines will look as they do in your sandbox screenshot, irrespective of the theme being used or the number of spaces typed before the single return.

If you have that setting toggled on, the theme might still be controlling the look of single returns.

To me, the sandbox screenshot looks as expected if the ‘strict line breaks’ toggle is off:

1. Two returns make a new paragraph
2. One return makes a new line in a longer paragraph or in lines of poetry
3. SPACE SPACE does not create a line break as it isn’t meant to

In the image below, there are no spaces at the end of each line, just single returns.

• With the toggle on, single returns don’t create visible line breaks in reading mode. This is normal Markdown mode. To create a line break in reading mode with the toggle on, we would have to type: SPACE SPACE RETURN
• With the toggle off, single returns create visible line breaks in reading mode. This is more like a word processor where a single return creates a new paragraph.

Angel

EDIT: Apologies in advance if I have misunderstood anything.

[Duhkha]

@anon12638239, @efemkay, @CawlinTeffid I appreciate your help, thoughts, and patience. At this point, I’m guessing it’s specific to my main vault—setting, plugin, etc. I’m not sure yet. See below for elucidation.

First, @anon12638239 I realize that I do understand the line break syntax. In my haste, I simply made a mistake with my first example: two typed spaces without Return key function. Thank you for your reminder. So, I’ll just focus on paragraph breaks now. Also, Settings > Editor > Strict line breaks is off in all themes tested.

In my vault, I’ve tried Minimal, Primary, Comfort Color Dark, Obsidian default, and LYT Mode themes. Reading view paragraph break behavior is illustrated below. Specifically, paragraph breaks (pressing Return key twice) in edit mode do not render properly or as expected in Reading mode. They display as line breaks.

Here’s Comfort Color Dark:

Conversely, paragraph breaks do display as expected in the Obsidian Sandbox Help vault:

@efemkay, here’s my developer view, so margins do appear to be okay in Minimal, no? Info is the same in other themes mentioned:

Again, I’m truly grateful for everyone’s input. Before I do a nuke and fresh Obsidian install (thank god they’re only text files in a folder, right? ), any additional thoughts?

Blessings.

[anon12638239]

I am sorry to say that I am out of meaningful ideas. I know you have tried different themes, but what about the default theme? Same issue?

Perhaps you could message the theme developer and get their input.

I hope someone can solve this for you.

Good luck

Angel

EDIT: similar to this?

Space between paragraphs

[CawlinTeffid]

From the picture it looks like you are inspecting the Live Editor view, not Reading Mode.

Do you have any CSS snippets enabled?

[efemkay]

@Duhkha

@efemkay, here’s my developer view, so margins do appear to be okay in Minimal, no? Info is the same in other themes mentioned:

yeah @Duhkha, u did the right steps but as per CawlinTeffid pointed out u did in live preview/edit mode. do that same steps but in read mode. there should be a <p> element inside a <div> and by default (as in the sandbox vault), a para should have top and bottom margin of 1em or 15/16px. if u have 0px it means u have theme or snippet overriding it to be such.

here’s an example from my end. i select one of the para, and u can see the app’s default setting is p {margin-block-end: 1em; margin-block-start: 1em} but override it with p {margin-block-end: 0.5em;}

[Duhkha]

@anon12638239 @CawlinTeffid @efemkay Thanks again for your patience. Sorry for delayed response, but I was away on a work trip.

Ugh, this is an example of when I five minute phone call might save everyone time. @anon12638239, per my last post, I did test default theme and behavior is the same within my vault. The sandbox help vault, however, displays paragraph breaks in Reader as expected.

• I have no CSS snippets installed;
• I have not wittingly or intentionally changed a preference setting that would modify the <p> element.
• The only thing I’ve knowingly changed is Minimal’s header colors;
• I did contact Comfort Color Dark developer, but I have not received a response;
• Notice how in my vault, all themes, including default, show <p> is modified by user;
• By comparison, 1em is preserved in Sandbox help vault.

Here’s Sandbox vault:

Here are three themes in my vault—default, Comfort Color Dark, and Minimal:

Perhaps this is being caused by a plugin? I might just need to start anew. Agree?

But

• I can’t be the only user stymied by this;
• I’m a power user but not a developer if that helps—I know enough to get in trouble;
• I understand the basic .md and HTML parsing of line and paragraph breaks for rendered output, namely user/developer must indicate intent with various elements;
• Given the increased awareness and use of text and .md editors, however—even by the “laity”—I do think it’s fair to assume that Edit and Reader view would be consistent to an extent. With this in mind, it would surprise me if a theme developer would wander too far astray from 1em as the default, let user modify as desired and as capable based on experience. Other text editors I’ve used with Preview or Reader feature do seem to render output this way.

Again, I’m here to learn, I’m happy to be wrong, I know some .md syntax interpretations regarding this issue are incorrect. In this context, however, I think the spirit of my “expectations” or inquiry is not surprising.

Thoughts? With gratitude.

[Duhkha]

Oops, meant to write Reading not Reader view/mode.

[efemkay]

Oke. As i suspected. Something is overriding ur para margin see screenshot below.

The original para margin (user agent stylesheet) is being modified by a plugin or snippet (style). Since u mention that u hv disabled all css, then i suggest disable all plugins and turn on one by one to see the culprit. Make to restart obsidian (ctrl/cmd p > reload obsidian without saving) every plugin u enable to ensure fresh environment.

[Duhkha]

@efemkay Thank you. I am grateful for your help. Cheers.

[Duhkha]

As final follow-up, I found it was easier to delete Obsidian, including all related app system files and all hidden files within my vault, then reinstall to resolve this issue vs. disable individual plugins or delete themes to troubleshoot—the beauty of a folder of .md files. Obsidian had become a hot mess, even to the point of curtailing use. Back to a clean slate, and I also chose to be more deliberate about plugin choices and use. Appreciate all of your feedback and guidance. Blessings.