Metadata Visuals 0.2.0

Metadata Visuals 0.2.0

Metadata Visuals 0.2.0 is a major refinement of how visual metadata rules are applied across Obsidian. It brings the same field-and-value rule model to the places where metadata is most useful in daily work: note Properties, the File Explorer, enabled Smart Folders, and supported native Obsidian Bases views.

Create a rule once, then use it wherever that property appears. A Status / Draft rule can colour a normal note Property, a File Explorer note, an enabled Smart Folder, or a compatible Base value without adding colours, icons, or emoji to stored frontmatter. The visual treatment stays separate from the data unless you deliberately use a bulk metadata update.

This release also makes matching more predictable. Rules now have one consistent precedence model across supported surfaces, field names match regardless of capitalisation, and rendering work is more careful about keeping colours attached to the correct value as Obsidian updates its interface.

Highlights

• Use existing Metadata Visuals rules in supported Obsidian Bases Table and Card views, including embeds.
• Keep rule behaviour consistent across Properties, File Explorer, Smart Folders, and Bases.
• Resolve duplicate rules predictably: the first configured match wins.
• Match field names case-insensitively while preserving the spelling already used in your notes.
• Apply Smart Folder status visualisation and deliberate bulk metadata updates from the File Explorer.
• Benefit from broader automated regression coverage and release validation.

Obsidian Bases support

Metadata Visuals carries its existing property/value rules into compatible native Obsidian Bases. Enable Colour properties in Bases in settings; there is no second rule destination or Base-specific rule editor to maintain.

Native Table and Card views are supported, including Table and Card Bases embedded in a normal Markdown note. Multiple visible Bases can use the same rules independently. Colours follow the property and its currently rendered value, so sorting, filtering, scrolling, and virtualised rendering do not change what a rule means.

The same word can be coloured differently when it belongs to different properties. For example, Status / Draft, Stage / Draft, and publication-state / Draft can use red, blue, and purple respectively. Metadata Visuals colours only a safely isolated value; Base labels, titles, backgrounds, layout, and controls remain native to Obsidian.

Scalar values, straightforward links, and a single compatible value in supported Table/Card rendering can be coloured. When a multi-value or list presentation cannot be identified safely, it is deliberately left native rather than applying a colour to the wrong token.

Native Bases List view remains intentionally unsupported. List values do not reliably expose their originating property, so Metadata Visuals does not colour text merely because it happens to read Draft. file.* and formula.* Base properties also remain native.

Consistent rule behaviour

Metadata Visuals now uses the same matching contract across supported surfaces: the first configured rule that matches a field/value pair wins. This includes normal Properties, File Explorer presentation, Smart Folders, and supported Bases values.

For example, if your rule order is:

1. Status = Draft → red
2. Status = Draft → blue

then Draft is red. Move the blue rule before the red one when you want blue to take precedence. The result does not depend on which interface is open, the order in which Base rows render, or the position of a File Explorer row.

Case-insensitive property matching

For matching purposes, Status, status, and STATUS identify the same field. This avoids a capitalisation-only difference causing one surface to colour a value while another leaves it native.

Metadata Visuals does not rewrite your frontmatter keys or alter their displayed casing. Existing metadata keeps its spelling, and bulk updates reuse an existing matching key where one is present. The change makes matching consistent without imposing a naming style on your vault.

File Explorer improvements

Choose one File Explorer field to provide optional note-name colour and icon presentation. The selected field prevents unrelated rule groups from competing to decorate the same note row, while Properties and Bases can still use all relevant groups.

File Explorer updates now focus on the relevant visible rows when Obsidian redraws its workspace. That keeps decoration responsive during normal navigation and expansion while avoiding unnecessary presentation work for unrelated interface changes. Metadata Visuals also removes only the colour it owns, preserving a newer inline colour supplied by another theme or plugin.

Smart Folder improvements

An enabled Smart Folder is a File Explorer folder that inherits an aggregate visual state from its descendant notes. It uses the selected File Explorer field when that group has compatible To Do, In Progress, and Done rules available for folders.

All recognised To Do descendants produce a To Do folder state; all Done descendants produce Done. A mixed To Do/Done folder, or any descendant explicitly marked In Progress, produces In Progress. Folder notes and direct-child Dashboard notes are excluded so a folder’s own summary note does not determine the folder’s state.

Smart Folders share the same first-match precedence and case-insensitive field handling as other Metadata Visuals surfaces. Enable or disable a folder from the Metadata Visuals File Explorer context menu; Colour enabled folders controls whether enabled folders receive their visual treatment.

Bulk metadata workflows

The File Explorer context menu can apply a configured field/value to selected notes or folders. Selecting a folder applies the raw value to its descendant Markdown notes, and overlapping selections are handled once per note. This is a deliberate metadata-writing workflow: it changes frontmatter values, not just their appearance.

Changing an ordinary visual rule does not rewrite your notes. Rule changes update compatible visible UI; bulk update is the explicit action for changing stored metadata across a group of notes.

Safer rendering and cleanup

0.2.0 strengthens the safeguards that keep visuals attached to the correct element. When a visible value changes, becomes unmatched, or is recycled by a native Base view, Metadata Visuals re-evaluates its current property/value pair rather than retaining a colour from a previous row or card.

Only the matching value receives the plugin’s colour. Property labels, Base card chrome, table headers, controls, and unrelated Obsidian UI remain native. When a rendered element disappears, the plugin releases its visual ownership cleanly. If another theme or plugin changes an inline colour after Metadata Visuals has applied one, Metadata Visuals does not overwrite that newer colour during cleanup.

Reliability and regression protection

This release includes an automated regression suite with 89 tests covering rule matching, Properties, File Explorer refresh classification, Smart Folder aggregation, Bases Table/Card value handling, List-view safeguards, property isolation, and colour cleanup.

GitHub Actions now runs the regression suite with lint validation, and release packaging runs the tests before the production bundle is built and attested. These checks do not guarantee that every future issue is impossible, but they provide a substantially stronger safety net for the behaviour Metadata Visuals already supports.

Compatibility

Metadata Visuals 0.2.0 requires Obsidian 1.12.7 or later. The plugin manifest does not restrict installation to desktop-only environments.

Bases is a native Obsidian feature whose rendered presentation can change over time. Metadata Visuals supports the compatible native Table and Card structures described above and intentionally keeps uncertain or ambiguous structures native.

Upgrading from 0.1.x

Existing settings and rules continue to work; no settings migration is required. The most noticeable behaviour changes are deliberate:

• Duplicate matching rules now use first-configured-match precedence everywhere.
• Field names match case-insensitively without changing existing frontmatter key casing.
• Supported Bases Table and Card values reuse the same rules already configured for Properties and File Explorer.

Review any deliberately duplicated rules after upgrading and arrange their order to express the result you want.

Known limitations

• Native Bases List view is intentionally left uncoloured.
• Bases file.* and formula.* properties are not styled.
• Ambiguous multi-value/list rendering may remain native.
• Themes can affect contrast and native control presentation; choose rule colours that remain legible in the themes you use.

Feedback and bug reports

Please report issues through the project’s bug-report form or suggest improvements through the feature-request form. Include your Obsidian version, Metadata Visuals version, affected surface, field/value rule, and a screenshot where possible. Avoid sharing private note paths unless they are essential to the report.