Native support for Inline (Intext) properties (`key:: value` a la dataview)

Use case or problem

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.

38 Likes

How would you delimit the value? Like, how are we supposed to know that “5km” is the value and not eg “5km in the mountains”, if that comes after?

3 Likes

Currently dataview uses a period as a delimiter, so this would work ran:: 5k. in the mountains.
Other options could be:

  • One word only, unless surrounded by quotes: ran:: "5km in the mountains" today
  • Customisable delimiter: ran:: 5k:: in the mountains, for example.
7 Likes

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:

  1. Configuring specific YAML fields to support links and tags
  2. Showing errors in YAML parsing in the editor
  3. 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.

26 Likes

related, and wouldn’t incur non-standard markdown syntax Allow links in YAML front matter; Notion-like databases from metadata; links as first-class citizens - #16 by tabulo

2 Likes

burmp…

and

+1

1 Like

bumping this up

2 Likes

Use case or problem

Obsidian can recognize aliases and tags in “Inline Fields” because if they exist in the form of arrays in YAML, they will be modified.

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.

Related feature requests (optional)

3 Likes

Use case or problem

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.