Better block references via quote block

[mano]

I’ve come up with a hacky way to set up block references better in obsidian (for some use cases).

From the past few versions, obsidian has a way to reference any block in a note.

But what constitutes a block is not obvious in all cases. This becomes more difficult if you have multiple lines, or you want to give the block some structure like headings and tags.

If you know that the block will very likely be referenced elsewhere, how should you compose it? Making another note about it an option, of course, but there plenty of use cases where one may not want to do that.

I coopt the quote-block to do this. The entirety of the quote is one block, and there’s styling that demarcates its boundaries, so it does solve a few problems.

The huge advantage is that the contents of the quote block are rendered as markdown independent of the main note, so there is a lot one can do with the block in terms of structure.

The following screen shot illustrates this (edit on the left, preview on the right)

The first example is a simple block, but the second one about code mirror hotkeys is a more complex block with 2 levels of headers (h3 and h4) tags, tasks, inline-code etc. (The item marked done is just to illustrate capabilities).

I’ve even inserted my own meaningful reference string to find it easily later. (I don’t know how robust this part is. There have been no problems in my testing.) You can even use the same reference string in different notes (I haven’t tested in the same note), so you don’t have to worry about duplication.

Writing markdown inside quote blocks may seem daunting at first, but it’s actually pretty easy:

1. write regular markdown in the note
2. inspect the preview (with practice and/or the right theme, you may not need this)
3. insert > at the start of every line you want to make a part of the quote-block
4. inspect the preview

Depending on the elements you want to include in the quote block you may only need to precede the first line with >. It’s called lazy formatting I think.

At a later point if you want to create a proper note for this quote-block, you copy the entire block to a blank note and remove the >. Your formatting stays as intended. Make sure the block reference stays put, along with a link to the new note. If you do this correctly the same block reference will forward you to the new note.

alternatives

headers

you can link to headers. There’s an elegance and simplicity to it, but you may not always want to mess with the structure of the document just because a block might be referenced later.

I prefer referencing headers when appropriate.

code block

there are other forum posts describing how to do this, and ideas for plug-ins that can utilize the code block. That could be the right way to go about this in future.

But for now, the biggest disadvantage is that tags are not recognized inside the code block (and with good reason). Also, formatting inside codeblocks is not great even if you define the language as markdown.

styling

The default styling for a quote block may not suit this purpose. In the screenshot I have modified it to closely mimic a note (because it will have markdown elements in it), but stand out enough to know that could be a separate element.

I would like to have borders on the top and bottom of the quote block in edit mode but I haven’t figured out how to do that as of now. A discussion on discord didn’t yield the solution. yet.

This is the styling I use:

/* usage of `!important` is not recommended */
/* I use it here because this is WIP */

/* the following is defined in my dark theme */
/* --attention4: hsla(0, 0%, 25%, 0.50);*/
/* you will need transparency here*/
/* to show cursor selections properly*/


.cm-s-obsidian span.cm-quote {
  color: unset;
  background: unset;
}

.HyperMD-quote {
  color: var(--text-normal);
  background: var(--attention4) !important;
  border-left: 1px solid white !important;
  border-right: 1px solid white !important;
}

.markdown-preview-view blockquote {
  background: var(--attention4); 
  border-radius: unset;
  border: unset;
  padding: 10px;
  margin: unset;
  margin-top: 10px;
  margin-bottom: 20px;
  border-left: 1px solid white !important;
  border-right: 1px solid white !important;
  
}

.markdown-preview-view blockquote p {
  margin: 0 10px;
}

[pjeby]

Rather than try to write your markdown in quotes, you may instead want to use the “Format Hotkeys” plugin, which has a command to toggle blockquoting. Basically, if you want to reference a bunch of stuff together as a block, you can just select it afterwards and use the toggle blockquote command.

The plugin can also remove blockquoting (e.g. when you want to split it out to its own note), but it seems to be a bit quirky at the moment with how it handles blank lines; in my experiments it sometimes removed blank lines when unquoting. Still, it beats the heck out of trying to edit markdown inside a blockquote! (And perhaps the quirkiness will be fixed at some point.)

(Another option is to edit your blockquotes by opening a note in Typora: its WYSIWYG mode just styles blockquotes differently and you don’t lose any of the nested formatting or ease of use. You can easily add or remove blockquotes from any selection as well.)

[mano]

great, suggestion. This is essentially how I was using it (without the formatter hotkey).

But since then, I’ve abandoned this approach in favour of just writing blocks (lines of text without gaps in between). I didn’t like that I had to keep changing to preview mode to look at the block-quote in it’s full formatting, and I’ve learned to mentally treat blocks as one unit

[pjeby]

I’ve been playing a bit with block IDs today, and it seems that all of the following can be labeled as blocks, as long as the ^blockid is on a separate line:

• Unordered lists/task lists (blockid must have a blank line before it)
• Fenced code blocks
• Tables
• Blockquotes

I’m curious whether anyone has seen any other structures that work that way. Until I read this thread, I didn’t know you could put a block ID on anything larger than a paragraph, and until I accidentally block-linked a table today, I didn’t know you could put the blockid on a separate line after the target block.

(Being able to give IDs to things like tables is an opportunity for plugins, since one could put data in the front matter keyed to the block ID, for a plugin to do something fancy with the table. For that matter, the part where block IDs are indexed in the metadata cache with detailed positioning data means you can practically treat them as fields for query and display – assuming you manually assign block IDs, anyway.)

[mano]

I played around quite a bit with block ids back when they were released. I didn’t come across any homogenous element that cannot be referred to by a block id. The limitation though is that you can’t refer to more than one type of element with it. For instance something like this:

these are my hobbies:
- dancing 
- swimming
- writing

cannot have one block id since it’s a combo of a paragraph and a list.

That limits it’s use, IMO.

Anyway if you want to test it out properly try typing [[^^your_content_here]] in a note. Obsidian automatically generates the id.

Some blocks work well with the block-id inline, and others with one blank line in between. iirc, if you manually put an id inline, at the end of a list item, you refer to that item. but if you put it at the end of the entire list, you can refer to the entire list.