I’m copying a comment from @ShaneRobinson in this thread to provide a different perspective in support of standard markdown links, namely in being able to be used in a Github Pages/SSG site, not just as a local PKM tool, which is my desire and surely that of many others.
Blockquote
Oh… Yeah. You’re correct that MediaWiki-style [] links don’t work or convert to GHPages or an SSG (like 11ty, Hugo, etc…)
I don’t use [[]] links in Obsidian. I use standard Markdown text format which works perfectly in Obsidian. And allows me to “lable” the link anything I want instead of whatever the File Name is.
I also have TextExpander quick keys that generate an entire set of FrontMatter Keys and Values at the top of each file. Again, I’m working mostly in VSCode and only use Obsidian for viewing the Graph or backlinks…and with FOAM there’s less round-tripping between VSCode and Obsidian.
For me, I’m really not concerned about the Graph or backlinks when I’m working/writing.
My thinking/process is basically:
1. In order to maintain as much open format and interoperability in the future, stick to content and file format standards.
2. For the few internal/external links in each document, it’s not that much of an inconvenience (especially with quick keys) to use standard text syntax. This ensures I can serve any .MD file I have with any SSG and/or use any standard Markdown converter now and in the future. And when I’ve finished the document, I do have to manually at Tags to the Frontmatter “tags” array. Adds 2-3 seconds per tag, but guarantees I’ll have taxonomy connections between files when published through an SSG.
3. Placing Frontmatter at the top of each file also guarantees future interoperability, conversion, and hosting via SSG. Using TextExpander makes this super easy and fast.
It’s that old tradeoff of simply changing a few workflow elements (using text instead of [] for example) to benefit from exponentially more interoperability.
I’m all in favor of keeping Wikilinks, and am relatively indifferent if its the primary link method or not. But what would be good is just to have a similar search/autogeneration function for markdown links. Or even a tool to convert wikilinks to markdown links (with the page title becoming the link name, unless there is an alias).
it’s possible to use specific plugin converting [[ links to standard one in Jekyll or Gatsby …
WikiLinks is a great addition to Obsidian - and should definitely be kept. My point is that because Obsidian’s philosophy is based on not locking-in the user , they should not be offered as the primary solution. As much as we might like them, they are proprietary - and not as widely adopted (or standardised) as we might think. Compare how it’s done in The Archive, DEVONthink and Bear apps.
I disagree. Wikilinks [[ become more and more adopted. Drafts and Tinderbox adopted it lately (even if this is an artificial similarity because in TB imported markdown files [] links doesn’t work); The [[ links are understood by Zettlr, and even The Archive …
Instead, I would support setting links to “normal markdown” when exporting (if this option will be created or someone will build as a plugin)
You suggest that Wikilinks are becoming a standard, but 3 of your 4 examples are Mac-only, and the 4th (Zettlr) has a very small user base when compared to note-taking software generally. Your evidence is thus insufficiently persuasive. We should have support for real Markdown links.
[1] The [[ solution is not “tool agnostic”, is it?
[2] The most valuable asset to preserve in a zettelkasten are the connections between notes, are they not?
Bear, Devonthink, The Archive, Draft, Zettlr, Tidlywiki, nValt are using [[ ]] syntax …
The argument that most of it are Mac are proving only that most of the developed note-taking mac is for mac and the other OSes dont have that many nice tools …
In general backling-linking not taking approach is just gained popularity and I think the user base will be growing
I’m not against support real Markdown links, not all app support [[ ]] or support it in different way (so there is a with linking notes nested deep in folders) but this will be changing.
Having read this thread (and also other related discussions) in this forum (and also outside this forum), I still feel I haven’t received an answer to a basic question that currently haunts me:
should I - from the start - work with wiki or markdown links as the default?
Given that:
I want all my notes and links as future-proof and app-independent as possible;
In obsidian, as far as I can see, both link styles work the same, without any limitations (including the backlinks function) - am I right?
So are there short and simple arguments concerning the following question:
What would be the advantage of wiki-style links as compared to markdown links (or the other way round)?
Apart from that it’s a question of whether you want to maximise compatibility with the past or future. Most of the newer link based apps use wiki-links and older ones are introducing them. Most traditional markdown editors use markdown links, though a few have added wiki-links.
Making the links future proof does mean that you need to predict the future.
I suspect there will be conversion utilities around for quite a while.
After thinking about this subject, dealing with bug reports, etc. I’ll give my argumets for wiki-style links.
Negatives of Markdown links:
They are way more move verbose, and you should use %20 or <> to handle whitespaces.
There is no (easy/natural) way to define a link to a note that doesn’t exist yet but might be created in the future (or if there is a way, it’s implementation nightmare)
There is no spec for linking to header (but maybe there will be one?)
They are not as easy to work with from an implementation standpoint.
Negatives of Wiki-Links:
There is no spec for wiki-link, but given how popular they have become and how many devs are implementing them, I am confident there will be one.
@Dor and @WhiteNoise, thank you both for your short and clear replies!
@WhiteNoise, the negatives you mention refer to markdown in general, I understood? Because all this stuff works perfectly within obsidian at least - actually both markdown and wiki links work exactly the same here (no problem linking to headings with markdown links either).
And you’re right, links to headings aren’t understood by other markdown editors, but at least they open the respective file for you when you click on the link - yet I just tested wiki-style links in 3 different markdown editors (re-text, ghostwriter and typora) and all three even didn’t recognize wiki links at all…
So I’m still not completely convinced, even if I like the idea of wiki-style links. But what I take from my experiments so far is the following:
within obsidian it doesn’t matter anyway - it all brings you to the same results;
but markdown links can at least be opened in any other editor (even if it doesn’t take you to the exact heading), whereas a couple of editors doesn’t recognize wiki links.
Actually, for now, only a small number of editors do recognise them.
It’s important to understand the difference between the links and their use cases.
Standard markdown was for web pages etc. Links were infrequent, usually to external files but with an option for internal. Documents were otherwise standalone just like a word processor.
Wikis were all about links, mostly internal.
The first placed most reliance on specifying the precise file and path - speed mattered less because they were done less.
The reverse for wikis because linking was done so often the wiki was its own construct so there was no gain spending time specifying file and path more than necessary.
Obsidian and the other knowledge based note programs are built around linking and so ease and speed matters. That’s why they all go for wiki-links. They all, more or less, go for markdown because it is plaintext (therefore easy to process) and is a pre-existing standard of sorts. They all add extensions when they need something that doesn’t exist in a markdown standard - nothing new there.
Realising the power and popularity of the linking paradigm, older programs are rushing to add wiki-links.
Editors don’t have the same need, and most of their users are just using them as document processors. They will change slower, and only if they perceive their users regarding it as a must have feature.
I think that day will come, you may not.
For now standard links will cost time and effort in Obsidian and other programs that allow wiki-links.
Wiki-links will cost effort and probably time if you often use editors that don’t understand them.
The best future proofing guarantee is the ability to convert (Obsidian has said it will provide a converter to standard links).
Would you be willing to give some examples of these older programs? If I’ve used (or am using) any of them it might give more understanding of the nuances regarding wikis.
Thank you so much for listening to your users and implementing this feature. Is it possible (or could it be implemented) that there’s a setting to use relative links and to create a hard-coded backlink with standard markdown links?
I have an existing markdown notes library that I’ve curated by hand (with some help from VS Code extensions) and feel drawn to Obsidian because of its mission to use a vendor agnostic format like markdown. However I’ve been burned in the past by adopting ‘flavors’ of markdown that were promised to be gaining popularity and widely supported. I’d like the option to, by default, use standard markdown reference style linking.
This feature seems to allow that but does so without acknowledging folders. I.e. Obsidian will do [Folder/note](note.md) instead of [note](./../folder/note.md). This seems to break in any other editor I tried. The functionality I’m envisioning is:
I have folder structure:
folder-a
– note-a.md
folder-b
– note-b.md
In note-a.md I type [[note-b]] at the top of the note
This expands to:
[note-b][]
This is some other text in Note A
[note-b]: ./../folder-b/note-b.md
In note-b.md
Some text I already had in note b
[note-a]: ./../folder-a/note-a.md
This is a clean way for both notes to have a strong connection using standard markdown syntax.
Perhaps I should just create the VS Code extension myself, but judging by this thread there’s a solid interest in standard markdown linking. Also, I love what you’ve done with Obsidian and would love to dive in head first. This is the only deal breaker for me.
I’m trying to use “standard” markdown links in notes that I know I’ll need to use on a mobile device with IAWriter (at least until Obsidian mobile exists), but it appears that standard markdown links are still not clickable in edit mode. Is this (lack of) functionality intentional?
