Use case or problem
Many plugins require dynamic markdown, but there is no standard way of displaying such views.
Proposed solution
Adapting an existing class like MarkdownPreviewView to allow views to be created with custom Markdown, in lieu of a TFile, to streamline many plugin applications.
Current workaround
ItemView
Right now, you can use ItemView to render custom Markdown, but there are many Markdown behaviors not implemented in this view:
- Inner links and tags do not render as expected
- Must add “user-select: text” to CSS to allow text selection
- Headers do not render in outline sidebar
- codeblocks do not run as expected (i.e.
query)
So developers independently implement these features, leading to inconsistencies (see: ItemView issue)
Other Methods
Otherwise, you can use a Code Block Post Processor to insert Markdown into the page, or create new Markdown files in the vault.
Code blocks lack the user-friendly nature of modals, commands, etc. to customize behavior. For example, to use Dataview you need to write in special syntax.
Creating files lead to file glut when lots of Markdown needs to be dynamically generated even when the user doesn’t really need to save the result. For example, a tags pages plugin creates tons of duplicate content for heavy tag users.
Both code blocks and file creation make sense when you want to save the dynamic markdown output, but for ad-hoc actions like search, they make less sense.
This also reduces interoperability IMO, as it leads to mixing of Obsidian-only content (plugin logic) with universal content (valid Markdown), even when it isn’t needed.