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.
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.:
Or by accessing markdown content using headers or block IDs, e.g. taking this:
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.