I’m using tweego v2.1.1+81d1d7
with SugarCube v2.35.0
Does anyone know what version of Gecko first supported background images? Or have I declared my background image incorrectly?
ETA3: Now I’m thoroughly confused. The background image is working fine when loading the story from borogove. It fails when viewing a local file, showing a blank background. Other browsers work fine with the local file.
I just discovered that a background image isn’t rendered by the current version of Waterfox. I’m testing with its current version, G.3.2.6. It’s an alternative to Firefox, based on Gecko 78.14.0. See https://www.waterfox.net/
I’m using this construct in the passage :: Story Stylesheet [stylesheet]
This declaration works fine with the current version of Firefox and the other browsers I’ve tested it with.
ETA: “background.webp” is the name of the image file. Waterfox has no problems showing WebP images in other situations.
ETA2: tweego has translated the image file into an in-line base64-encoded passage, just as it has many other images. This problem was encountered while viewing the Tarot “story” that I recently uploaded to https://g25br5qk.play.borogove.io/
If the image filename is “background.webp” then you can’t just put “[img[background]]”, you have to put “[img[background.webp]]”. Also, the “background.webp” image file has to be in the same directory as the HTML file, or that won’t work.
Furthermore, I should note that some web browsers, such as Safari, only have partial WebP support, so some WebP images won’t work in them. I’d strongly recommend sticking with PNG images for images that have sharp edges and solid colors, or JPEG images for just about everything else, since they have much better support in most web browsers than WebP currently has.
I’d also strongly advise against using base64 encoded images for anything but very tiny images, such as icons and the like. Base64 encoded data causes unnecessary file bloat and poor performance due to eating up more memory in the browser, since it ends up being an encoded format (the image) within an encoded format (base64 encoding) and thus also has a larger file size.
In any case, if the image isn’t loading, I’d recommend opening up the Console section in the Developer Tools window (F12 and/or CTRL+SHIFT+I in most browsers) to see what errors are being reported there regarding the image. Most likely the path and/or filename is simply wrong, thus the browser can’t find the image.
As I mentioned, I’m using tweego, which incorporates images into the html file by default. Since it makes the images into passages, no filetype needs to be specified. Also, since no additional directories and files have to be distributed with the compiled html story file, this is a big advantage, so far as I’m concerned.
I’ve tested the story with the iPadOS variant of Safari (I don’t have a Mac) and all of the images show up fine. I decided to use WebP because the WebP image files are much smaller than their PNG counterparts (e.g. 9KB vs 88KB and 34KB vs 585KB for the story’s covers’ images). The difference isn’t quite as dramatic for the background image, though (88KB vs 96KB), since it consists of tiny white specs (stars) against black space which compresses quite well. For the JPG images I’m using, WebP produces files which are significantly smaller, too, only slightly more than 1/2 the size, totaling 1.32MB vs 2.11MB for 80 images. Switching to WebP reduced the story’s html file from 5MB to 3MB.
I have to disagree with your description of inline image problems, at least for this story. The time taken by the system I/O overhead of opening separate image files is much greater than decoding base64. In this case, at the level of human response times, the time is imperceptible, anyhow.
Thanks for reminding me about the Console key bindings, although F11 = full-screen for Waterfox. The only warnings it reported were lines I thought I’d commented out and were related to fonts. I deleted them and the warning flags (exclamation point in a yellow triangle) shown in the Inspector went away, but there’s no change in the symptom (background image not rendered). The base64 encoding of the background image is shown in the Inspector’s middle column, and is rendered properly (in a new tab) when I select (double click on) it.
However, the Console shows the Warning message
Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content.
I don’t know what that’s implying, but it seems like it might be relevant.
What might be forcing the Layout?
However, this also seems to be a red herring, since this same Console Warning message is seen when downloading from borogove, which does render the background image.
Very strange.
Thanks a lot for your help and for the pointer to your Backgrounds collection!
No, it doesn’t. It doesn’t do it unless you tell it to compile a directory which includes images, thus it doesn’t do it “by default”. It’s your choice whether to incorporate the images or not.
And even if it did do it by default (it doesn’t), I’d still recommend against it for the reasons given earlier, plus those given further down below.
As for your comments about the image formats, that doesn’t change the potential lack of support problems I mentioned, which, admittedly, aren’t as bad as it was when Safari didn’t support WebP at all. Also, JPEG and WebP have compression settings (and, technically, PNG does too, though it’s a lossless format, so it means less), so your comparisons of file sizes aren’t valid unless you’re also making sure that the resulting images are of roughly equal image quality (and no, you can’t simply eyeball that), since otherwise all one needs to do to get different file sizes is to compress them to different quality levels. When all things are equal, WebP’s file size savings over JPEG are meager. Trust me, I worked deep in imaging technology for an imaging software company for seven years, so I know what I’m talking about here.
Regardless, format support is likely more important than file size, since I’d hope you don’t want broken images in any browser.
But, if you’re that worried about file sizes, then that’s yet another reason to avoid using Base64 encoding, since that will bloat up the file sizes by between 33%-36% (source).
This depends on the amount of data that you’re talking about, whether it’s being downloaded or is local, etc., but regardless, you’re failing to take into account the amount of memory used. I’ve seen a game where they put in enough Base64 encoded images that only Firefox could play it properly due to the amount of memory required to handle all of those Base64 images. That game’s HTML file was “only” 82.9 MB in size (huge for an HTML file, though small for a whole game with lots of images). Removing the embedded images and making them separate files reduced the overall file size and made the game work on all browsers again.
That’s the reason why that functionality, which had been in the Twine v1 editor, was not added to the Twine v2 editor. It causes too many problems, especially for mobile browsers, which have much less memory available to work with.
The fact that you’re encountering problems with images in only some browsers suggests that you may already be hitting the memory limitations in those browsers.
Oh, sorry. Yeah, F11 is fullscreen in most browsers. I meant F12 shows the Developer Tools window in some browsers. (Fixed my earlier post.)
That’s a Firefox/Gecko warning, which you can ignore, since it’s not relevant to the way Twine/SugarCube does things.
Anyways, I’d use the images as external files, instead of embedding them as Base64 data, and that will most likely fix your problems.
I currently have all of the related textual and image files in the same directory tree (not same directory), with only its root specified to tweego. That helps me keep track of which files and images are used for which purpose.
I’ve been using ImageMagick’s default quality settings when converting image file formats (by not specifying any). Visually, the images all look satisfactory to me, so they’ve not lost enough quality to matter.
Note that the total size of the html currently is only 3 MB, not the problematic 80+ MB that you mentioned.
I explicitly tested several browsers this morning (Brave, Chrome, Comodo Dragon, Edge, Firefox, Opera, Tor, Waterfox Classic, Waterfox G3.2.6) under Win10 Pro 21H1. I also tested several under iPadOS v15.0. (Un)fortunately, I encountered this problem in only one browser: Waterfox G3.2.6 under Windows. All of the others worked as intended. sigh (Unfortunately, I’ve found Waterfox support to be, shall we say, less than optimal.)
I’ll try a file reorganization as you suggest to see if that helps.
I copied the files to a new directory tree and changed [img[imagename]] to [img[images/imagename.webp]] in several places (including the background image) for testing. Firefox and Waterfox Classic both show the background image. Waterfox still does not. pffft
Despite my poor previous experiences with them, I’ll try reporting the problem to Waterfox support on reddit. Using a much simplified example, of course.
Have you tried it using standard CSS notation, instead of SugarCube’s special [img[]] notation?
If you looked at the CSS for “Backgrounds” example I gave you before, you’d see that it does it like this:
body.single-background {
background: url("images/space-1.jpg") center center / cover no-repeat;
}
That assumes that you want the whole image to cover the background with no black bars on any of the edges, but you can change/remove the stuff after the url() part if you want to do things differently.
Give that method a whirl to see if it works for you. If it does, then it must be a quirk of how SugarCube is updating the CSS from SugarCube style to standard CSS.
As far as I know, it’s a two man operation that maintains two separate Waterfox releases (Classic & Gx) based on the Gecko repo—though I believe they do accept PRs.
I’m unsure how responsive they are in general, but WebP background images does seem like a curious omission, especially from the Gx releases, so reporting it is what I’d suggest.
EDIT: It’s all background images? Yikes! Yeah, that’s definitely bad.
The [img]-in-CSS notation simply transforms into a url() function whose parameter is either the specified URL or, in the case of an image passage, the stored data URI. There’s nothing really interesting about it.
Yeah, I poked around a little bit earlier: Waterfox is doing some weird things with the CSS: some rules just don’t seem to show up at all in the inspector?
It looks like Waterfox doesn’t recognize the “body” class.
The code below works ( <div class="bkg"> ... </div>) for example.
but if I replace “.bkg” by “body” in the “style”, no background image is rendered.
Replacing “.bkg” by “body” does work when viewed by Firefox and Waterfox Classic.
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<style>
.bkg {
background: url("background.png");
}
</style>
</head>
<body>
<div class="bkg">
<h2>Background Image Test</h2>
<br/><br/>
<p>Waterfox G3.2.6 does not show background images which have been defined in a "style" declaration. It should.
</p>
<br/><br/>
<br/><br/>
<p> Current versions of Waterfox Classic, Firefox and other browsers do.
</p>
<br/><br/>
<img src="foreground.png" width="200" hright="200">
<br/><br/>
</div>
</body>
</html>
I’ve had a few issues with .webp files. To avoid problems with different browsers I convert them to .png or .jpg files if I want to use them as background pics.
