Forbidden tag characters are allowed in properties

Steps to reproduce

  1. In the sandbox vault, add the following to the top of the “Start Here” note:

    ---
    tags: [test.ing]
    ---
    
  2. Search tag:test.ing.

Did you follow the troubleshooting guide? [Y/N]

Y

Expected result

No results, because “.” Isn’t allowed in tags. Tags - Obsidian Help

Actual result

“Start Here” appears as a result.

Environment

SYSTEM INFO:
Obsidian version: v1.3.5
Installer version: v1.3.5
Operating system: Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:19 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T8103 22.5.0
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 0
Plugins enabled: 0

RECOMMENDATIONS:
none


Additional information

To verify it’s not a false positive (matching tag:test because of word splitting or something), search tag:test — no results.

Tags in the note body automatically end at “.”.

This bug was discovered when @ClareMacrae was experimenting in the Insider build to see what constitutes a tag in Obsidian. The discussion starts at Discord.

This bug was reported before but closed in what looks like a misunderstanding. It is possible to create a tag with dot

3 Likes

Lots of other symbols validate as tags, including curly and straight quotes in the sample below.

Wonder what properties makes of them in 1.4.x

---
tags: [test.ing, work;ing, do:ing, lov*ing, say"ing, play'ing, hop’ing, slop”ing,]
---


EDIT

Perhaps ties in with this:

Alias wrapped in quotation marks splitting at comma - Bug graveyard - Obsidian Forum

The same thing happens with tags.

And:

YAML entry with commas within quotation marks should produce a single entry - Feature requests - Obsidian Forum

To repeat myself in the bug report, the current behavior is not standard.

(Not referring to tags directly but insinuated from the first link.)

And:

YAML entry 1.4

In v1.4, this divergence from the standard is being addressed. We will begin with rewriting the incorrect form to a compliant one and eventually (at some point in the future) stop supporting the incorrect format.

(Not referring to tags directly but insinuated from the first link.)

1 Like

They appear as valid YAML/ Properties “tags” …

They’re accounted for and searchable too …

The #atag auto-completor suggests them when adding a #atag in the content of a note …

… But no, they’re not considered as valid / work as #atag once inserted in a note as they’re split at the invalid character (or inserted, as I tested this earlier, as a string for numerical Properties tags)

In other words, there’s still an inconsistency in how Obsidian treats YAML / Properties tags vs. note content #atag … which, from a user point of view, might generally be confusing :thinking:

I guess there might be some reasons to not restrict the use of forbidden characters in Properties / YAML for tags (as they’re valid YAML and these tags containing “forbidden” characters might be useful to some) but then I don’t really see the point of suggesting them in the content of a note (as they won’t work as such anyway) or simply not allowing “forbidden” characters in #atag all together… And by that I mean : if they’re valid Properties (YAML) tags, IMHO, they should also be valid or work as note content #atag as written/used in Properties

Unless, these characters are forbidden in note content #atag because other markdown processors might also not allow them ? :thinking:

In any cases, if the inconsistency can’t be fixed in a way or another, I agree with @ClareMacrae : The inconsistency could be highlighted/explained a little bit more in the documentation :innocent: .

(Take this with a grain of salt though, I’ve never been a big user of tags/#atag :innocent: … The conversation on Discord just got me curious :blush: )

3 Likes

Many thanks for the insight. Feel like I am anomaly tripping.

Hope it will all be rationalized one day.

1 Like

I think they’re forbidden for compatibility/simplicity. “Most or all platforms that support hashtags permit the inclusion of letters (without diacritics), numerals, and underscores. Other characters may be supported on a platform-by-platform basis. Some characters, such as & are generally not supported as they may already serve other search functions.” — Hashtag - Wikipedia

I’d guess the behavior in YAML is unintentional. Probably forbidden characters should be disallowed in the “tags” field and treated like body tags elsewhere.

1 Like

Interesting :grin: ! Thank you very much for these precisions :blush: !

will be fixed Desktop 1.4.6

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.