Previously on the CogitActive Saga:
You don’t have to worry about the size of the container; it will size automatically. On the other hand, it’s a good idea to set the size of the transparent image to the same size as the to-be-protected image.
All the way back in the early days of this blog—when I was still laying the groundwork and figuring things out—I tackled the challenge of protecting my images. After all, creating unique visuals for this blog required time, effort, and a bit of creativity. Letting them be freely taken, whether by ignorance or intent, wasn’t something I was willing to accept. Among the many solutions listed in the aforementioned post, one technique caught my attention: the HTML table method. The concept was simple yet intriguing—overlay a transparent image on top of the actual content to thwart easy right-click theft.
In my follow-up post, Overlaying an image with a transparent one, I delved into this approach, initially attempting the table-based background-image method. However, I soon realized its limitations and pivoted to a more refined CSS-driven positioning technique, ensuring better accessibility and responsiveness. Not only did this adjustment effectively deter casual image theft, but it also preserved a clean, seamless aesthetic—a clever workaround that felt like a victory at the time.
To achieve this, I used the following CSS:
.first {
position: relative;
}
.second {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
}The corresponding HTML structure looks like this:
<div class="first">
<img src="URL OF THE TO-BE-PROTECTED IMAGE HERE" alt="ALTERNATIVE TEXT HERE" style="width:500px;height:500px;">
<img class="second" src="URL OF THE TRANSPARENT IMAGE HERE" alt="ALTERNATIVE TEXT HERE">
</div>To streamline implementation, I created a Reusable block (now called a Pattern) within WordPress, eliminating the need to manually rewrite the overlay setup each time:
<div class="first">
<!-- PASTE THE ENTIRE HTML COPIED FROM THE IMAGE BLOCK. Move any styling (e.g., alignment) to the class of the div tag. -->
<img class="second" alt="All right reserved" src="URL OF THE TRANSPARENT IMAGE HERE">
</div>For years, this protection mechanism worked quietly behind the scenes, preventing casual image theft without requiring any attention. I had little reason to revisit the code—it functioned seamlessly and was fully integrated into my workflow.
That was, until recently, when I stumbled upon something unexpected. What seemed like a minor detail at first turned into a deeper investigation—one that revealed an invisible flaw lurking beneath the surface. The flaw is no longer invisible—it’s time to fix it! This post is about retracing my steps, uncovering the issue, understanding why it happened, and ultimately refining the solution.
The invisible barrier
What began as an ordinary task—copying a snippet of text from an older post for my “Previously on the CogitActive Saga” introduction—took a puzzling turn. A simple action, one I had done countless times before. Except this time, I couldn’t do it. The text, somehow, was untouchable. I frowned. Tried again. Still nothing. Annoyance settled in—I was in a rush, and this was the last thing I needed. Instead of digging deeper, I found a workaround, grabbed the text another way, and moved on. A glitch? Maybe. An odd quirk? Possibly. Either way, not my problem right now.
But then came the second encounter. While testing a newly added tooltip—part of my ongoing efforts to enhance usability—I noticed something strange. The tooltip was supposed to appear when hovering over an internal link, providing a brief description of what the reader could expect. A small but helpful detail. Yet no matter how many times I hovered, clicked, adjusted my title attribute, rewrote my <a> tag, and scrutinized my HTML, nothing worked.
The blame game began. First, I suspected my tooltip implementation—perhaps I had missed something? No. Then, maybe it was a browser quirk—was the tooltip behaving differently in certain environments? I checked multiple times. Everything seemed fine. I cycled through suspects, my frustration mounting as I tore through the code, trying to pinpoint the flaw. But that was exactly the problem—I wasn’t looking at the flaw itself. I was focusing on the smallest details instead of seeing the bigger picture. I was fixated on the tail of the elephant, completely missing the elephant in its entirety.
Then, I finally stepped back. Took a breath. Really looked at the issue. And that’s when I saw it. I couldn’t select text. I couldn’t activate tooltips. I couldn’t even click my links. It wasn’t just me. My readers were affected too. They couldn’t interact with tooltips, couldn’t select text, couldn’t even click my links. Everything was covered.
But covered by what?
You’ve probably guessed it by now. But for me, it took a little longer. Until I saw the image above.
The protection that went too far
When I finally set aside time to tackle what I assumed was a minor issue, my first step was simple: check other posts for comparison. Maybe I had messed up something specific in that one instance. There had to be something different about it—some overlooked tweak or misstep that had caused the problem. But as I sifted through post after post, an unsettling realization took shape. It wasn’t just one post. It was all of them. The invisible barrier stretched across my entire blog, quietly obstructing interactions across multiple posts. What I thought was an isolated quirk had turned into a systemic problem.
The realization hit like a shockwave—something was seriously wrong.
This bug wasn’t just frustrating—it was actively hurting the site’s usability. Without functional links, navigation was compromised. Without tooltips, helpful context disappeared. And without selectable text, basic interaction suffered. For a blog that values accessibility and user experience, this invisible wall wasn’t just an inconvenience—it was a serious flaw that needed fixing before it quietly affected more posts.
A few quick tests (with the help of the Inspect Element feature) revealed something unexpected—the protection overlay wasn’t conforming to the actual dimensions of the images it was meant to cover. Instead, it was a square (e.g., 512 × 512 px), regardless of the original image size (e.g., 512 × 235 px). This explained why it was unintentionally spilling over the text below, but it didn’t explain why it was happening. This was where the real detective work began.
Except, I wasn’t armed with a magnifying glass and years of expertise in HTML or CSS. What I did have, however, was a keen sense of observation and deduction—the perfect tools for unraveling the mystery piece by piece. But how do you play Spot the Difference when you don’t even have a correct version to compare against? So, I began my search—post after post—hoping to find one where the protection was still working as intended. After all, the code had functioned before. Hadn’t it?
This was no easy task. First, as longtime readers of this blog may recall, images became scarce after that fateful summer of 2020. Second, even when I did have images, most were screenshots—and I hadn’t applied the protection to those, since there was little need to safeguard visuals I hadn’t created myself. Still, I persisted. The code had worked before… hadn’t it?
Finally, I found one. An older post—using the exact same method—that didn’t have this problem. The overlays matched the images precisely, working as intended. What had changed?
| Good code | Bad code |
|---|---|
| |
From a quick glance at both codes, one detail stood out—the ‘good’ one had an extra <div>. Could that be the key? Spoiler alert: yes, the missing <div> wrapper in the problematic version was causing the overlay image to stretch incorrectly! Fixing it was simple enough—I updated my template (i.e., reusable block) to include this extra <div>, restoring the intended behavior:
<div class="first">
<div>
<!-- PASTE THE ENTIRE HTML COPIED FROM THE IMAGE BLOCK. Move the class with any styling (e.g. alignment) to the above sub-div tag. -->
</div>
<img class="second" alt="All right reserved" src="URL OF THE TRANSPARENT IMAGE HERE">
</div>But while that part was easy, figuring out what changed—not in my template, but within WordPress itself—and understanding why this <div> made the difference was an entirely different story. Or two, actually!
To be continued…