Hidden headings could be a great way for people to introduce block style identifiers to their markdown.
A hidden heading would not show in the Preview, and would allow block level referencing without adding visual clutter where a heading would otherwise not make sense.
So many people migrating to Obsidian want better block/section embedding options. This is one way to help them without diverging from markdown principles.
Approach Suggestion:
There are multiple heading styles in markdown to take advantage of. Obsidian could commit to the ## Section Atx-style for normal headings and use the underline style to render those headings as hidden.
Hidden section title of a block that will be embedded somewhere
------
Content of the interesting block
By default, the hidden heading should also be hidden wherever the content is embedded. So both Preview of the source content and embedded content would simply be
Content of the interesting block
Alternatively, maybe Obsidian could introduce a 7th heading level so that
####### These headings would be hidden but still embed referencable
Designating a specific type of heading to be hidden wouldnât compromise the markdown integrity of our content either. Should we migrate, the heading would simply become visible and parse friendly if the future app environment provided similar rendering options.
As an additional way to manage embedded sections gracefully, this is related to
HTML comments are already allowed and invisible in Markdown - for example:
<!-- REFERENCES SECTION -->
Some programmersâ text editors make use of this feature to allow the programmer to create âbookmarksâ that are automatically picked up by the app. Usually, this means using some extra characters to indicate that this is a âspecialâ comment, that should be picked up as a bookmark. For example, using the hash character as the first character in the comment might signal it as a bookmark:
<!-- # BOOKMARKED SECTION -->
These âbookmarksâ could then be picked up by a spacial panel, or via a plugin. Is that what you had in mind?
Thatâs such a great feature to point out! But special panels and external plugins are not what I have in mind here. There are thousands of potential users coming from Roam. Many of them are resistant to migrating because Obsidianâs Section Embedding pales in comparison to the block level embedding available in Roam.
What Iâm suggesting is a possible way to satisfy most of their needs within a markdown framework thatâs also compatible with the approach that the Obsidian developers have already taken.
I am, however, into your suggestion of using HTML comments. Being that itâs already allowed and invisible in Markdown, itâs a fantastic idea and has so much potential! Combining it with your suggestion of using special characters, It could be used to make Obsidian better in numerous exciting ways!
It seems like a perfect integration tool to facilitate many plugin ideas that are brewing.
There are also several Plugin Idea threads that introduce UID management to emulate block style embedding. They tend to rely on solutions that deviate from the self-contained markdown philosophy. And I think some of them are really great ideas. Iâm eager to use them if they are created.
How does hiding a header turn text into a Roam-type block? From what I understand of the Roam system, is that ever line is a bullet is a block. In Obs text under a heading may consist of more than 1 sentence, therefore of more than 1 line.
Well itâs up to you as the user to choose how much text you want in this referenced section. Thatâs a good thing.
Iâm not claiming that it turns it into a Roam-type block. Try not to box yourself into thinking that we have to do the exact same thing as Roam to get most of our needs met.
This is just a suggestion that brings us closer to the embedding utility that many users want while staying in the markdown framework.
But if it is not what I suggested, then what is the point of suppressing a header?
If that header is just above 1 sentence, then @ryanjamurphyâs suggestion of surrounding that sentence with double square brackets is a simpler solution. Or am I misunderstanding your solution?
Edit: I just saw your link to @benperkinsâs workaround with the 6 # in the #general channel. Is that what you mean?
I just discovered the suggestion by @benperkins myself. Yes, it sacrifices one of our heading levels, but it provides a great proof of concept for the idea.
How embeds are shown depends on your CSS. Some of us see the section title in addition to the content in every embed. The option of a hidden section title is one way to give you a choice on how it presents.
@ryanjamurphyâs suggestion is very cool and definitely has utility. But itâs impossible to include any rich content. Latex or Mermaid, no way. Most symbols are out of the question. And for those of us that like using directory structures, it creates such a mess of file clutter. Also you lose title referencing which really simplifies organizing content for some people like me. But thereâs an entire thread dedicated to that technique. It doesnât need to be repeated here.
People organize their their thoughts differently and having various options is a good thing when making an organizational tool.
Having a custom reference is a nice functional middle ground between hidden UIDs, section titles, and associative naming. I like the approach the developers are exploring for embedded sections. It just needs some polish.
?
The issue is that exRoamers have identified block linking as the missing feature.
But it isnât. Block links in Roam are part and parcel of its foundation as an outliner working through a database. That encourages a particular workflow. And you canât duplicate outliner advantages with documents - they have very different advantages, like better data security. In many ways the nifty feature in Roam is its document view hiding the outliner base.
Block links are fine. Setext headers may be an option. But they wonât duplicate the Roam experience. Outliners are faster for some types of notetaking and organisation.
Personally, I need a good documentation tool that handles transclusion elegantly and can produce exports that will format well for publication. It seems like Obsidian has the potential to be exactly that.
Though Roam does both outlining and transclusion, which is probably the reason for so much crossover in discussions, the outliner workflow is a different discussion than creating an elegant transclusion workflow. Or, I at least hope to keep that differentiation in this thread.
I really just want Obsidian to get transclusion dialed in and I believe itâs entirely possible to do it well, even within the limiting framework of markdown.
Just a quick note: if youâre using sentence-level blocks, you donât need to create a file for it to work. [[You can just link a sentence like this]], and then youâll be able to use the exact phrasing/transclude it elsewhere.
But yes, your other concerns are the drawbacks of this technique. No mermaid in file names ;<
I donât know @ryanjamurphy, I donât think you should be pushing this method so hard. Users are going to lose their work if they rely on it. Itâs neat that it sort of works but itâs a rather precarious trick to place much faith on.
Itâs just too easy for the blocks to fall out of sync. Any inline editing breaks the connection. And technically, not having to create a file is true? But creating a file is a necessary extra diligence if you ever want to change anything in the block and keep all instances in sync.
Clearly people are interested in your technique. So it really should exist as a proof of concept demonstration and be filed as a highly desired feature request. Your technique should be turned into an actual feature with a dedicated symbol or maybe triple brackets. That way Obsidian could manage it in a robust manner.
@Klaas, No @ryanjamurphy is correct. You can create as many links like that as you want and a file wonât be created. But if you you Ctrl-click the link, the file will then be created. Try it out. It is pretty cool.
@goodsignal Good point re: changes to the sentence not auto-updating. I donât edit these blocks after I create them. Indeed, if the devs are interested in making this less of a workaround and more of a feature, Iâd advocate for a different syntax and auto-updating too.
@Klaas Aye, thatâs the problem goodsignal was describing.