fix(view): don't collapse paragraphs in a block view field - #673
Open
nelsonlove wants to merge 1 commit into
Open
fix(view): don't collapse paragraphs in a block view field#673nelsonlove wants to merge 1 commit into
nelsonlove wants to merge 1 commit into
Conversation
nelsonlove
added a commit
to nelsonlove/obsidian-meta-bind-plugin
that referenced
this pull request
Aug 14, 2026
A BRAT build of upstream 1.5.1 plus the block-view paragraph fix (mProjectsCode#673) and nothing else. Cut from the 1.5.1 tag rather than master deliberately: master carries two unreleased upstream commits — a new optionSource feature (~840 lines) and a speculative "maybe fix mProjectsCode#667" — and a local install should not inherit those just to get a CSS fix. Versioned `-nl.1` so it sorts above 1.5.1 and below 1.5.2: upstream supersedes this build on their next release. Retire it once mProjectsCode#673 lands.
A view field already tags itself `mb-view-inline` or `mb-view-block` from
`renderChildType`, but styles.css never referenced either class: the inline
rules applied unconditionally. So a block view rendering multi-paragraph
markdown had its <p> elements forced to `display: inline-block` with zero
margin inside an `inline` wrapper, and two paragraphs ran together on one line.
Collapsing is right for an inline view — it sits inside a sentence and must not
introduce block flow. It is wrong for a block view, which has a line of its own,
and there it silently destroys the author's paragraph breaks.
Note which element carries which class: ViewFieldMountable puts
mb-view-block / mb-view-inline on `targetEl`, and mb-view-wrapper on the child
div it creates inside it, which is also the element TextVF marks
mb-view-markdown. The mode therefore has to be matched on the parent — a
`.mb-view-wrapper.mb-view-block` selector matches nothing.
Scoped `:not(.mb-view-block) > …` so the inline case is unchanged, a block view
inherits Obsidian's own <p> styling rather than being counter-styled, and a
wrapper with no mode class (JsViewFieldMountable) keeps what it had.
Reproduce: a note property holding two paragraphs, rendered with
`VIEW[{prop}][text(renderMarkdown)]` in a ```meta-bind block — the blank line
between them disappears.
nelsonlove
force-pushed
the
fix/view-block-paragraphs
branch
from
August 14, 2026 07:48
98f6420 to
479b79f
Compare
nelsonlove
added a commit
to nelsonlove/obsidian-meta-bind-plugin
that referenced
this pull request
Aug 14, 2026
Corrects nl.1, which shipped selectors that matched nothing: mb-view-block sits on targetEl, the parent of the .mb-view-wrapper element, so the mode has to be matched on the parent. nl.1 was a no-op. Upstream 1.5.1 plus mProjectsCode#673.
| Written as :not(.mb-view-block) > … so a block view inherits Obsidian's own | ||
| <p> styling untouched, and every other case — including a wrapper with no | ||
| mode class, e.g. JsViewFieldMountable — keeps exactly what it had. */ | ||
| :not(.mb-view-block) > div.mb-view-wrapper.mb-view-markdown > p { |
Owner
There was a problem hiding this comment.
I don't really think the long comment is necessary. One sentance or no comment at all should suffice. Also I wonder, why you did not use .mb-view-inline > div.mb-view-wrapper.mb-view-markdown > p instead of :not(.mb-view-block) > .... Same applies on line 76.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
A view field rendering multi-paragraph markdown loses its paragraph breaks when it's a block field:
with
renders as one run of text.
MarkdownRenderer.renderproduces two<p>elements correctly — the CSS then flattens them.Cause
ViewFieldMountablealready tags its wrapper fromrenderChildType:but
styles.cssnever referenced either class. The inline rules applied unconditionally:Two zero-margin
inline-blockparagraphs inside aninlinewrapper sit side by side, so the break disappears.Collapsing is correct for an inline view — it lives inside a sentence and must not introduce block flow. It's wrong for a block view, which has a line of its own.
The change
CSS only. Scoped with
:not(.mb-view-block), so:<p>styling rather than being counter-styled, so they pick up the theme's paragraph spacing automatically;This mirrors the
.mb-input-inline/.mb-input-blockpair that already exists for input fields — the same distinction, just never wired up for views.Verification
bun run build,format:check,lintandtypecheckall pass. Confirmed the compileddist/styles.csscarries the scoped selectors, and reproduced the original behaviour against 1.5.1 in a live vault.