Make #tags also [[pages]]

I’m not sure what your point is, sorry. The OP wants tags to be pages. No tags pane there either.

I don’t see any mention of removing any existing tag functionality.

1 Like

Me neither, but the implementation implications are unclear. If tags are pages, why is there a tag pane? Are tag-pages special pages that show up only in the tag pane? If so, they are no longer tags to me. I suspect you won’t find unity on that in the user base.

Again, this idea is conceptually muddled. This may seem like “just make tags pages,” but there are no justs in design.

1 Like

I agree that it is lacking scope and thorough justification. Examining it further, the tag pane itself is a plugin while tags themselves are nothing more than a CSS selector, essentially. This request would make more sense as a plugin (providing the API would allow for this functionality) rather than a built-in feature.

1 Like

OP here.

For people curious to see how a system where tags and pages are both regular links might look see RoamResearch and RemNote.
Their approach was to make them both first-class citizens, and then differentiate between them where appropriate.

To answer some concerns:

  1. Speciality of tags/extra functionality - all “special” functionality can still remain, simply treat the links that start with a hashtag-# as a tag. Tag panel can show links that begin with a hashtag.
  2. Graph view polluted by tags or not needed - graph view can easily distinguish between links that start with a hashtag. No reason graph view cannot have an option to “show tags” or “hide tags”.
  3. Tags are “different” from pages fundamentally/philosophically - that distinction can still remain, simply based on the syntax - #tag will “mean” a tag. [[page]] will mean a page. However, some people may choose to use these differently and don’t need to make this semantic distinction.
  4. Why not do it via [[#tag]] or some other specialized syntax? Because it increases the complexity of my notes and adds to the noise.

Again, this feature request is to make it part of obsidian, without compromising on existing functionality but only adding additional features. Everything possible with tag system now will still be possible with tags as pages.

Hopefully this clarifies my position, but I’m by no means suggesting that this is the best and the only way for this to work. I just want to bring this to devs attention as I think it will improve the software.

14 Likes

I don’t mean to spam/self-promote, but I created a Feature Request that I think is very relevant to this request: [ Copy page links from Tag and Backlinks Panes to clipboard

The idea being that you could extract links to any page that appears in the current Backlinks Pane or is associated with a tag in the Tags Panel. You use #tags or [[links]] to your preference, and then easily create a summary page as is requested here. Check it out and lend support if you think it would be useful!

2 Likes

Excellent ideas here.

2 Likes

I would really like to see this feature. And I think the reason for it is more apparent now that tags are a distinguished by a special color/toggle in graph view (like earlier posts alluded to)

Alot of people (especially a lot of ex-Roam users) work by using Tag pages ( aka #[[tag]] ) as a catch all or hub. More interestingly, a lot of MOC users do something very similar (and may not realize it) when they use MOCs. (I’m an ex-Roam users who loves MOCs now :smiley:)

The clearest way I can describe the rationale/functionality is this:

  1. The role of the tag classification is to distinguish from “regular” notes. The same distinctive role is often filled with the use of MOCs. Whereas notes are generally declarative statements or at least a few words, tags and MOCs are usually single words and more like umbrellas. I think everyone is in agreement here

  2. Being able to write notes in a tag page would allow you to use the tag as a workspace for incubation. This is why many MOC users use MOCs for the structure of their notes instead of tags – MOCs are tags on steroids.

  3. Using [[tag/MOCName]] obviously removes the phsyical distinction between tags and regular pages/notes, and even worse is not taking advantage of (imo) Obsidians biggest strength: visual representation–which, like i mentioned is even more useful in the latest update. MOC users currently have to sacrifice this functionality

  4. This probably leads you to ask why not just use “[[#tagpage]]” or [[moc_Page]]? Well bc when you use that as the heading of your note, then in order for the backlinks to pick it up, you have to always use #tagpage in your other notes and is completely useless when looking for unlinked mentions. This completely ruins the idea of the “smart hub.” Again, MOC users also have to sacrifice this function.

I think even more useful feature in the future (could be a plugin), would be other tag prefixes, such as @[[name/source/alternativeheirarchy]], for even more visual and theoretical distinction. Since Obsidian seems to be distinguishing itself from a lot of other backlink focused apps (especially roam) with its extremely powerful graphical views, this would play even more into Obsidians strengths, especially with a toggle and special color in graph view for those alternative prefixes.

(edited for clarity)

10 Likes

+1 for what @ishgunacar said.

Hadn’t thought of this. Seems obvious in hindsight, and much cleaner.

I’ve been reading this thread and unless I’m misunderstanding something…you can toggle tags on and off in the graph view. The option is in the Filter portion of the menu.

There is a blog post from Tiago Forte on tagging, which among many things covers tags as statuses:

It is lengthy but a very insightful read.

If you’d like to follow Tiago’s journey from not liking tags at all, to liking them a bit more, here is a post from 4 years earlier:

Both are interesting reads.

4 Likes

Hi everyone,

Here’s my thought process for this:

Some tag features:

  • Tags are a shortcut to a search function, but this function is limited. I cannot use regex with them (for example tag:/^#string/), such as tags starting with something or ending with something. In this specific sense, a tag is inferior to a normal search.
  • Tags are weak links between concepts, as there is not a specific page to tie the two concepts together. Sometimes you just want to relate two or more things without creating a page. We should keep that.
  • Tags have a dedicated panel
  • Tags look different in the document

Today I was wondering, should my dates be tags or notes to link to? The concept of daily notes calls for the later, but there are cases where I just want to tag something with a date as to not create a page. So right now I feel like I should be using both tags and notes for my dates, and tags only for when I don’t need the page.

So, a realization came to mind, a link [[]] can become a tag if Obsidian makes three changes:

  1. A key combination, something like Alt + Click that when pressed instead of going to the page, it becomes a search function such as "[[string]]".
  2. An option in the configuration to ask before creating a page with a link click, in case the page does not exist before. This has to be paired with a visual signal to differentiate which links have pages created and which ones don’t. There are many options here, color, adding a pound symbol at the start of the link like #[[string]], etc.
  3. A way to save searches and/or to have links be listed in a separated panel. Similarly to the tag pane.

These three things would make the concept of links [[]] contain the concept of tags # with the added benefit that there would not be restrictions for multi-word tags (no needed to join with -,_, etc.)

Another plus is that there would not be an unnecessary worry if a concept should be a link or a tag, as the link would serve both.

The big con here is that there would be two competing features that overlap with the same use-cases, making things confusing for the users. So there should be a clear path of implementation paired with an option for users to massively reformat notes, in case this comes to fruition (similar to the markdown importer).

Thoughts?

1 Like

What’s being proposed here accounts for what’s been discussed elsewhere:

With a somewhat clear set of features on how to achieve it.

1 Like

This two things for me are positives of tags and pages being separate entities. I actually like that they have a dedicated panel that let’s me know how many of a type of page I have. They also serve as visual queues for me. Can you guess in this note where is my important tag?

I think having a tag glossary is important, tags can get out of control. I’m curious in which cases doesn’t it make sense to create a page? Also… creating a link doesn’t create the file itself until you click on it, AND it still shows up in the graph as a connection.
Adding a panel that lists all the links in the graph would soon be impossible to navigate.

@argentum

They also serve as visual queues for me.

But this is using custom CSS, right?

In that sense what’s being shown in the screenshot is achievable with internal links too, especially because it has data-href attributes and these also have .internal-link .is-unresolved classes. Which allow for the same result you just showed, and I could argue even better, here’s a demo:

All these are internal links no usual # tags used:

[[tag new unexisting page]] <-- this is a tag without page created

[[tag important]]  <-- this is an important tag, unique color no page created

[[tag important with page]] <-- this is an important tag, unique color with a page

[[Ideas]] <-- existing page, this is not a tag

[[a page but not a tag]] <-- non existing page, not a tag

[[tag existing]] <-- this is an existing tag with a page for descriptions (if anyone likes that)

All tags are multi-word

And here’s how this very page renders:

And the css used is very small:

.internal-link[data-href^="tag "] {
  color: white;
  padding: 1px 8px;
  text-align: center;
  text-decoration: none;
  display: inline-block;
  margin: 1px;
  cursor: pointer;
  border-radius: 14px;
  background-color: var(--text-accent);
  opacity: 1 !important;
}

.internal-link[data-href^="tag "][data-href*="important"] {
  background-color: red;
}

.is-unresolved::before {
  content: "⚠️ " 
}

So the basic structure is there, it’s just missing some considerable steps in order to make it work like a full tag.

In the end the points mentioned above would be still missing given the current behavior of links.

My point is, the links and tags are very close in terms of UX and having links absorb the benefits of the tags, all of them, would provide a better experience.

5 Likes

That’s a fair point! I still think that the separation is good and a “links” pane would be rendered unusable as the vault grows.

It’s still unclear to me on which cases a date doesn’t make sense as a link and does as a tag, and especially now that I’ve seen that you can format links in such a way. Wouldn’t that make links work for you? You could use only links pretty much in the same way by pretending tags don’t exist in obsidian.

This is pretty much what I’m using right now, the problem is I’m not able to quickly search for something the same way a tag works. One feature of tags is that they serve as shortcut for the search function. So the points mentioned above are still fundamentally missing:

  1. A key combination, something like Alt + Click that when pressed instead of going to the page, it becomes a search function such as typing "[[string]]" in the search bar, similar to tag:#string.
  2. An option in the configuration to ask before creating a page with a link click, in case the page does not exist before.
    1. This has to be paired with a visual signal to differentiate which links have pages created and which ones don’t. There are many options here, color, adding a pound symbol at the start of the link like #[[string]], etc. This is addressed with the custom CSS.
  3. A way to save searches and/or to have links be listed in a separate panel. Similarly to the tag pane.

I still think that the separation is good and a “links” pane would be rendered unusable as the vault grows.

I’m not sure how the internals work, but if we are able to build a graph with thousands of notes, I don’t think a searchable list with a number of mentions for each link is too far fetched.

1 Like
  1. Couldn’t you select the text and press ctrl+shift+f?
  2. Since there is a visual distinction you click on a link that is unresolved, and it will create the file? How are you imagining this works if you click but don’t create the file?
    About the styling… You can already do this with is-unresolved can’t you? And I’m no css expert, but wouldn’t you be able to use before:: for this too? It’s not very clear to me if you think something other than the custom css should be added.
  3. You can already star searches!

There are vaults that range anywhere from 200 to 38k notes, I think once you have more than 100 links, finding stuff in that pane is going to be hard or need a lot of scrolling.

These are all UX/UI improvements transformed features that can make the [[page]] work like a tag.

  1. That could be an alternative, for now, but I could see my self (potentially other users) easily miss-clicking and navigating to the page instead of searching, but yes. I still think a key combination is a small UX improvement to add here.
  2. There are two things here, the option to “confirm to create (through link navigation)” and the styling.
    • The styling is easily solved as shown in the demo above.
    • Perhaps there’s a better way, but the config option is an UX improvement similar to what we have as an option on “Confirm to delete”. One can easily create a bunch of blank pages, and the users might not necessarily want that. Especially when the current styling for is-unresolved is simply opacity: 0.5; it’s an easy mistake to make. This is not as related to the tag discussion but it does indeed help to align the tag/link behavior: because clicking a tag does not create a page and a setting like this might impede the creation of undesired pages (which might happen if the devs do decide to go down a similar path)
  3. That’s very useful to know! I wasn’t aware of it. I can easily make some adjustments to my workflow with that. In all honesty, I’m very new to Obsidian, just a couple of days-old user here.

There are vaults that range anywhere from 200 to 38k notes, I think once you have more than 100 links, finding stuff in that pane is going to be hard or need a lot of scrolling.

I see your point, but I do wonder if the people who manage all these notes would be interested to know the top mentioned links and these be shown as a list (that’s what the tag panel practically does). And for the same people who have more than 30k notes, how many tags do they currently have?

1 Like