4. We start to include images 5. This might involve a diversion into the image externaliser
In the previous section of this turorial we saw that it was pretty easy to insert an image and have it delivered inline with the HTML page. (DID WE?)
Having the images inlined doesn't seem like a bad idea, until you consider the need to adapt content to different screen sizes.
With the image hard-coded into the page, we lose the ability to offer differently sized images for different clients.
Could we leave it the way it is and not worry about it? We could - but every mobile user of our site is likely going to have to download huge image files that they'll never see at full resolution. It'll make the site slow and waste data meaning fewer people will use it.
If we're building a toy site to learn new technologies or techniques, we might not need to worry about it but if we want to build a robust, live site that people will enjoy using, it's something that we need to deal with.
The problem seems quite hard.
I'm going to break it into two pieces
1. Getting the (one) image to be outside of the wiki and referenced correctly
2. Generating lower-resolution images and loading them when appropriate.
Before I do either of those things, I'm going to read about how other people have done static site gen in tiddlywiki, because I think this might well be a problem that they have at least thought about.
Now, let's think about these links.
The problem arises because there are characters allowed in Tiddler titles which are not allowed in URLs
And further complicated by the fact that sometimes they may be allowed if the web server supports them (?) viz - urls with whitespace at eg; neocities