A proposal for rendering block embeds inline

I feel there is no interest at all to work on this. Asked this some weeks ago in the Discord (inside channel) but without any response from the devs. I don’t know… I feel strange about this :slightly_smiling_face:

2 Likes

This quote hits at the heart of the matter for me. Each transclusion (instantiation) object has a different intent and usage; each with its own implied metadata.

I suspect the rendering (display) is trivial but the effect on the street warrants pondering. In my interaction with other PKM users, there’s only a small group of us that use block references. Obsidian is poised for huge influx of users in the short term. The bang for the buck may not be there presently.

Block references have taken on new meaning, for me, with the introduction of the canvas plugin. Gonna give this quote and thread some thought today. Great fodder here. Happy new year!

8 Likes

Would be sad indeed if inline embeds were not on the map anymore.
The devs of Make.md figured out a way to have editable block embeds - I wonder if it’s so hard to have them rendered inline.
Btw. TfT, if you manage to make your inline css work again, would you mind sharing it?

7 Likes
  • So I thought about and messed in Obsidian with notes, cards, and groups on canvasses with internal links of all permutations.
  • Notes and Links to Notes are first class citizens because they have inheritance and metadata or properties exposed to the UI.
  • We don’t appear to have much, if any property values defined and exposed for Obsidian internal links (also commonly called section and block links or simply, block references).
  • We could certainly css our way to some sort of short term solution, but we need persisting things like an optional foldable link title (ideally for each separate transcluded embed). The pipe Display Text item on a WikiLink for internal links seems appropriate (it is a known bug) and associated rendering properties for appropriate css.
  • The link title, for me, should render as a hover when cursoring over the embedded linked text in the manner discussed above in this FR.
  • Fully first class would be able to edit those internal embeds in the same manner we edit their parent note.
  • Since there are no standards in this area across the PKM realm, migration of data both into and out of Obsidian is a huge issue with regard to where we go with section and block references. There is much discussion about the function and appearance of how block references work on other PKM tools, but none of the various link structures are cross PKM compatible in the underlying interface api and syntax.
  • A happy ending. I have been hesitant in the past to use internal links until the last couple days; lets face it, they are messy and lacking and for final output, they suck. I now use them whole heartedly because even with their limitations, they be incredibly handy for research and drafting efforts in my vault. For now, I’ll continue to export from Obsidian into Scrivener for submissions.
  • And that is all ok. Besides, I have faith our developers, both core and community plugin folks, will get us to link utopia.
5 Likes

I second this feature!. It would be really benenficial if it were implemented. This is my only gripe with Obsidian! :crossed_fingers:

4 Likes

It is very sad if this is truly the case :frowning:

2 Likes

I would also love this feature!

3 Likes

… a big +1 for this feature!

2 Likes

It seems that Obsidian first has to solve the “linking to line/section/block” problem in a better way before the issue here can be addressed, as this issue (and others as well) will naturally make use of whatever mechanism Obisidian uses to solve the internal link problem. The current “footnote-exploit” ([^3bc4h]) approach is fragile and frankly a little ugly and cumbersome. More problematically, it is not a first-class citizen, which limits what we can do with it and also does not give us the magic refactoring.

For many reasons, if Obsidian offered a robust, reliable, ergonomic and minimal friction model for handling persistent links to constructs under the file-scope as first-class citizens (line, paragraphs, blocks, etc.) then it would truly elevate this app to a completely new scale of networked knowledge!

For now, though, it seems that the secret hack is to make any content that you wish to reference atomically a list item to define a subpage scope, and then use the current footnote-style internal link to reference it.

For example, given the following file:

%% source1.md
- This content will not show up if the  next is embedded
- so much depends upon  
  a red wheel barrow  
  
  glazed with rain  water  
  beside the white  
  chickens 
  
  ^slyk3i
- This content will not show up if the previous or next is embedded
- Three rings for the elven kings under the sky
    Three Rings for the Elven-kings under the sky,  
    Seven for the Dwarf-lords in their halls of stone,  
    Nine for Mortal Men doomed to die,  
    One for the Dark Lord on his dark throne  
    In the Land of Mordor where the Shadows lie.  
    
    One Ring to rule them all, One Ring to find them,  
    One Ring to bring them all and in the darkness bind them  
    In the Land of Mordor where the Shadows lie.
  ^qfvmeq

- This content will not show up if the previous is embedded

We have full control over what gets embedded – everything, arbitrarily complex, that is in the list item scope:

![[source1#^qfvmeq]]

![[source1#^slyk3i]]

Many drawbacks to this: ugly syntax, the friction/need for coming up with our unique id’s (plugins help with this), no magic refactoring as these subfile chunks get moved around, the need to forward-plan and put everything that we want to embed into lists etc.

8 Likes

+1 :sneezing_face::sneezing_face::sneezing_face:

3 Likes

Hoping for the feature request of inline embeds as suggested by the many voices here to be implemented.

4 Likes

+1 for this request!

4 Likes

+1 for this request

4 Likes

+1 for inline block references. Even a core appearance option toggle would be great.

Let the user decide how they would like their transclusions to render. The massive css hack isn’t sustainable longterm.

6 Likes

Huge +1 for this, would be great for personal wiki workflows!

3 Likes

Seems embeds still do not render inline with latest 1.3.5 and 1.4.1
Details Embed Adjustments: how to flush/strip padding · SlRvb/Obsidian--ITS-Theme · Discussion #240 · GitHub

Am I wrong?

2 Likes

+1. This would also probably help with this other popular feature request (made by WhiteNoise, one of the moderators): Edit transcluded (embedded) notes (blocks) in place (likely requires WYSWYG first)

3 Likes

+1 i would love this feature

3 Likes

I’m going to throw my vote in the ring for this feature as well. It’d make a lot of workflows & usages far simpler & cleaner.

4 Likes

Fully support this idea/request. I would love to see this happen. I really think people could/would switch to Obsidian more easily.

3 Likes