Which is a future proof way of referencing external images in tiddlywiki in markdown format

I know of two ways to reference local external images in my wiki in markdown format.

  1. ![](relative-path) using this syntax directly within a tiddler text field

  2. Using relative-path in the _canonical_uri field of the image tiddler and transcluding it using as {{image-tiddler}} . I got this idea after reading this comment by Mark. Best way to organise local files for a single file html wiki - #16 by Mark_S

Which of these two methods is future proof (in case I want to transfer these notes in markdown format within Tiddlywiki to another tool which recognises markdown format in the future)

Firstly, it’s a shame to hear you are thinking of abandoning TW.

(Note: I use WikiText instead of Markdown so you may have to convert to your syntax.)

For my part I reference most images using either <img> or [img[]]. I will usually do it the HTML way if using in combination with figure and figcaption, and the WikiText link way on most other occasions.

If you chose to move away from TW, the chances are that the next tool would not be truly automated, but I would also say that the format is not that complicated either, and it can be programmatically converted without much effort.

Standard HTML should be supported within most Markdown compilers, theoretically (not that it’s a real standard, but still).
The same cannot be said for Markdown-based tools, so you should probably avoid using HTML directly.

As to option #2, images-as-tiddlers would probably be less ‘future-proof’. I only create tiddlers for content that have meaningful content, such as magazine scans. If it’s just pretty headings or illustrations, they don’t need unique tiddlers. I cannot think of many other tools that follow TiddlyWiki’s model for storing information, so you might struggle with this style. Use it when it is meaningful in your data structure, but really consider if it’s necessary for them to be tiddlers.

My key question is if I could ‘consume’ the tiddler standalone to some extent. If not, then it should be an embedded img.

When I do have images as tiddlers, I always do them as _canonical_uri and follow a loose folder hierarchy (I don’t sweat this since hierarchies don’t represent the TW way).

Above all, I’d also say not to let the idea of possibly having to migrate put you off from using TW to its full potential.

Currently due to lack of time, I will reply just to this part. I don’t plan to abandon Tiddlywiki any time soon. But things in the far future are not in our hands rite. Tiddlywiki is the only software (among the plenty I have tested including onenote, obsidian, logseq, tana, remnote etc.) that I am still using extensively. Since I am using tw since 2020, i have acquired more than basic knowledge in tw and I am using it to create my own custom layouts, dynamic tables, video annotation templates, cloze flashcards, budget wiki. I don’t think I could have done any of these in rest of the softwares. So I don’t think I will leave tw anytime soon. But in case I wanted to use the same notes which I create in some other platform, it has to be stored in markdown format. For that reason and because of the concern about far future, i thought of storing my notes alone in markdown format. But I extensively use procedures, view template cascades, custom keyboard shortcuts, custom buttons, dynamic tables and so on. So I am definitely making good use of power of wikitext. Formatting i use for notes are limited to unordered list, bold formatting. So I don’t feel any difference between markdown and wikitext. Transclusions work with markdown tiddlers as they fallback to wikitext parser i guess.

@Mark_S how do you organise your images ? Are you using markdown ?

Is it [img[]] for wikitext and ![]() for markdown or using separate tiddlers for images with _canonical_uri field.

I’m pretty random, actually.

My last stab at being organized, I used a field “base-image” for the base name of the image in the _canonical_uri tiddler. This way I could rewrite the _canonical_uri field whenever I needed (so reference local images, images on a separate drive, or external images).

For future proofing, I might consider using something like

<myimage "myimagepath" "myimage.png">

Why?

So when the time comes, you can rewrite the “myimage” macro to output whatever format is needed by your future technology, whether that’s markdown, or php, or some other templating. And so you have the path separate from the image name. Then, for instance, if you need to remap the image name to a different image ID (like you would with Joplin), you could do the remapping maybe with a cascade inside of the macro.

In the mean time, you can just change “myimage” to whatever path you want for whatever platform you happen to be on.

On the other hand, if you’re actually thinking of some other platform, then you should future-proof for that platform. For instance, the mark-up approach would work out of the box in Obsidian.

That’s just my rambling thoughts. Others might have better insights.

It is difficult to make predictions, especially about the future. – Niels Bohr

Can you share a small demo of what you are doing

There is a md-to-tid plugin, Also there can easily be a tid-to-md plugin if someone need it. Just use gpt4 to inverse the logic and make a new plugin.

Md to tid plug in does conversion on per tiddler basis rite…can it do bulk conversion based on some filters?

It’s button must call an action widget, so I think it is possible. never tried it before, because I only use it when importing GPT result.