Skip to content

Webcomic layout hacks, part 2: For any website

Webcomic layout hacks, part 2: For any website published on 2 Comments on Webcomic layout hacks, part 2: For any website

Miscellaneous things I’ve done to customize my webcomic layouts. Part 1 covered edits that apply to comic-specific plugins, plus some definitions of the basic technical terms. These are more general things you can do on any Wordpress-based site, or, in some cases, any site at all.

(This is part of the “how do I webcomic?” series, with useful information on all kinds of comicking-related topics.)

Disclaimer: some of these are extremely hacky. If you know how to edit the actual underlying PHP, you’ll probably be tearing your hair out at how clunky they are. This is for those of us who are a few steps down the tech-savviness ladder.

But if you’ve worked out a more-elegant solution, feel free to drop it in the comments!

Automating social-media preview images

I wrote up a separate post about your comic’s preview images back in February, and it’s useful enough that I’m repeating the link here. Go check that out, if you haven’t already.

Automatic preview image

Spoiler cuts

Say you’re about to start a new story arc, and this is the one where Obi-Wan dies. You know some readers get really upset about surprise character death, so you want to give them a heads-up. But you know other readers hate being spoiled for big twists, and you want them to be surprised.

Solution: spoiler cuts! See them in action on this page. People who want the warning can open them; people who want the surprise can skip them. Win-win.


…This one’s very easy, you just install the Inline Spoilers plugin and follow the directions.

ROT13 is a low-tech, no-plugin alternative. Tried-and-true, it’s been used on the internet since the early ’80s — so, as long as there’s been an internet.

And, if I can soapbox for a minute:

Some people think the goal of warnings is “warn readers about every single instance of Potentially Upsetting Content.” Well, it’s not. Because that’s…not humanly possible. (Consider this very-partial list of phobias, which includes “chickens,” “numbers,” “stairs/steep slopes,” “knees,” and “the moon.”)

The goal is to offer warnings for a short list of common, widely-shared types of Upsetting Content. Focus on knocking out the big ones. Don’t knock yourself out trying to cover all the little ones.

There isn’t universal agreement about what goes on that list, either! There is no One Perfect Warning System. But as long as you use your best judgment, keep the warnings consistent throughout the comic, and stay open to reader feedback (even if you don’t follow it all) — you’ll have the important parts handled.

Putting custom HEAD code in all your pages

Another catch-all section, for the many and varied things I handle with the Head, Footer, and Post Injections plugin.

Header and footer

In the HTML head, it puts:

Before the end of the body, it puts:

And it all just works!

Really can’t praise this plugin enough. Simple, free, does the straightforward thing it says on the tin, which does so much.

Disabling “helpful” mobile features (swipe navigation, display of low-res images)

I do both of these with the Real-Time Find And Replace plugin. If you can’t find the underlying theme/plugin/option/code that’s generating a problem, so you can’t stop it at the source…this will do last-ditch text replacement, which erases the results right before the page is loaded.

Yeah, this is the hackiest thing here, I apologize upfront.

First issue: the archives were set so mobile viewers could swipe the page back-and-forth to move to the previous/next comic. The catch being that mobile viewers also needed to swipe back-and-forth to read the whole comic they were on.

It was being triggered by the presence of the class “data-webcomic-gestures.” (Pretty sure the Inkblot theme is what generates that, but don’t hold me to it.) So I replaced all instances of the text with a new, made-up class that doesn’t trigger anything.

Disabling mobile swipe navigation (Inkblot):



Replace with


Second issue: the archives were trying to automatically serve lower-res images to mobile users with the “img srcset” property. A well-intentioned effort to save people’s bandwidth! But I don’t post high-res comic images in the first place…so anyone who got a downgraded version found it blurry and impossible to read.

You can’t find-and-replace the URLs of every individual low-res image, because they’re different for each strip. But you can replace “srcset” with, again, a made-up property that does nothing.

Stopping the site from auto-delivering alternate low-res images:



Replace with


The “data-” prefix is an HTML5 standard. That’s right, there’s an official standard for “how to format made-up properties that do nothing.” (This is why you make sure you’ve got Professional Metadata Nerds writing things.)

And that’s it for Part 2

Questions, comments, special requests? Drop a line here. If there’s interest in enough other things, maybe someday I’ll group them together into a part 3.

Comment Header


Actually, the “data-” prefix is for sending variables to javascript, not for “doing nothing”. Also, the find and replace plugin knows regular expression and I think you would be able to search for those small images with regular expressions, but it’s easier to do it like this considering you don’t really need the srcset at all …

… and yes, better solution would be find what makes those in first place, but it can be hard even with PHP knowledge.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar