fancier images
26 Jun 2026 - digitalily
Among the minor things that I think enhance a website are images and how they're handled. Well, images in general obviously enhance a page, but it's the surrounding bits I'd been a bit concerned about. I have been using embedded images mainly in blog posts and in song/game pages, and while you could always right click to open in a new tab, it isn't a great experience, and is possibly annoying on mobile (which always finds its way into design decisions). And speaking of mobile, because of the area limitation many images would be way too small anyway, so something was needed.
Originally the thought was to just wrap the images in <a> tags, with to make them clickable and pop-up in a new tab, and while that functioned, it caused some friction with the css I use mainly for blog images to align them to one side or the other. I'm also not a huge fan of the extra browser tabs on my phone, and even on desktop it just doesn't feel like a great solution. I knew many websites had in-page viewers that expanded the image, included a bit of information about them, and allowed navigation, so I did some googling around and came across a javascript library called glightbox which does all these things. I was thinking of a way to roll my own solution, but having an open source library that works well (and in ways I don't yet even realize yet) is pretty great.
Implementation was relatively simple- just adding a class and a few properties to dictate the text, location of the text, and which 'gallery' it's in- something I haven't explored that much but I think is a way to stop being able to navigate through every image on a page if they are in different galleries. Add some css overrides to get it looking more like what I want, and voilà.
What made things a bit more complicated was that with this I was also looking to create WebComponent(s) for a few sets of tags that were reused commonly, such as those around images in blog posts. There's not an awful lot to mention there, other than the post files look much cleaner using the custom component. The internal logic just exists to make it a little customizable including things like position and border style. From this effort components for images, multi-images, song-covers, and iframes (for the as of writing one youtube video embedded) were created. I've elected to exclude the game covers for now since I think the detail is pretty readable as is and they're all really just borrowed assets meant to make the page they're on look satisfying, which I think they do.
That isn't the only upgrade to images though, as I also wanted to introduce spoilerable images. This is mainly going to be for future posts, to allow more spoilery stuff to be posted, but I also chose to do it since a couple of the cover images for some recent games could be considered spoilery. It's a little bit of a stretch, but better safe than sorry and also is a way to test it out live in a small way. Along with this, the first site wide options and a page for them were introduced.
I decided to have two controls for this, mostly because I don't think not wanting to see spoilered images on a collection of game cover art which you can trivially be exposed to means you should see everything unspoilered as a result, so you can choose to enable/disable for posts or just for game covers at the moment. This state is tracked by a cookie, but defaults to showing the spoiler overlay. I've already begun brainstorming a few other ideas for the options page, but those aren't a major priority at present.
Anyway, the implementation of the spoiler overlay was a bit rougher compared to glightbox, as this one didn't rely on anything external other than the svg for the icon. Before settling on an options page, I had a checkbox on the sidebar and originally thought of keeping that there, but it presented issues. I wanted toggling the checkbox to unspoiler/respoiler images depending on the previous state, and this seemed to work one way but not the other. If the page loaded with it unchecked (disabling), re-enabling would not apply the overlay. What this ended up being was a combination of two things- the first being that a lot of the initial javascript wasn't properly waiting for the DOM to fully load, which also impacted the overlay by making images 'flash' briefly, which defeated the purpose. The second issue was our good ol' friend css. The component responsible for the overlay was being hidden/unhidden properly, but it was stuck behind the actual image when toggling back and forth like this. It worked fine on load when enabled, but not when dynamically being applied. So that was fixed, and I subsequently moved the options to a separate page, so the situation can't really happen anymore. At least the code is more resilient? If you edit the cookie directly however, it won't work, I'm sorry to say.
That's all for now- until next time!