YAML can be unwieldy, and sometimes just doesn’t support certain values (e.g. links). It would also be great to give yaml fields in the content of a note.
Proposed solution
The Dataview plugin recently gave support for inline yaml fields in the content of a note. One can type key:: value in the body (not the frontmatter), and dataview recognises it as if it were key: value in the yaml.
I propose that Obsidian supports inline fields so that other plugins can also use this functionality. Ideally one would be able to customise the syntax (key:-> value, for example).
This would allow one to have a content value act as metadata without repeating oneself.
Today I ran:: 5km
Bonus points for:
Access to a library that can parse this syntax
Giving inline fields a css class for customisation
Current workaround (optional)
Dataview supports this, so it works with one plugin, but ideally all plugins could use this functionality, and Obsidian core.
I’m not really fond of adding another new syntax to Obsidian markdown. It’d be nice if this were done using either existing markdown syntax, e.g.:
Field
Value
Ran
5km
In
22:50
Or by accessing markdown content using headers or block IDs, e.g. taking this:
Related Links
[[this]]
[[that]]
[[other]]
And accessing it as a “Related Links” field.
I would much rather see Obsidian support ways of:
Configuring specific YAML fields to support links and tags
Showing errors in YAML parsing in the editor
Editing YAML without needing to know YAML syntax
These things would keep metadata more portable, as does using markdown headings. Creating new syntax means not just new parsing in Obsidian, but new parsing in every single plugin that has to deal with these new kinds of fields, and entire new classes of possible errors to sort out. As annoying as YAML can sometimes be, there at least already exist plenty of documents and tools for working with it. Anything new is just adding to the “now we have more standards” problem.
(And making delimiters configurable is even worse.)
I think the real root issue here isn’t YAML vs. body, it’s the fact that Obsidian doesn’t support updating links in the header, and doesn’t give you good feedback about the validity of your YAML. If those issues didn’t exist, there would be little reason to use the body instead of the front matter for this kind of data.
Provide the same styling and validation of frontmatter properties for dataview style inline properties, marked by ::.
Use case or problem
Example
In a daily note I have set up a habit tracker. I want to leverage the power of Obsidian properties, but would prefer to have habits listed inline with the document under a specific section.
Plugins (such as Dataview and Tracker) would have a clear markdown indicator of embedded properties the could pull from, if they chose to support it.
Proposed solution
In this situation I might be able to do the following:
## Habit Tracker
meditation::
work out::
nap::
medication::
Upon seeing the :: Obsidian would transform the entry into a visually similar property selector. They can be modified, removed, and re-ordered (if multiples are adjacent lines) in the same way the frontmatter properties are.
Current workaround (optional)
Simple add all properties in the frontmatter. Works, but doesn’t allow a page to flow as well as it might otherwise.
The Properties update was an amazing QoL improvement for a more consistent and efficient vault.
The problem is that this update didn’t improve the so useful inline properties.
Proposed solution
Just to make them behave and look like frontmatter properties to improve UX and consistency.
