Previously on the CogitActive Saga:
At this stage, I shared my workaround code, asking Gemini to analyze why it worked and whether it could be improved. Gemini quickly recognized that introducing an intermediary <div> allowed .first to correctly derive its height from the image, effectively resolving the misalignment problem. However, it also cautioned that while my solution functioned as expected, it wasn’t the most semantically ideal or robust in terms of CSS.
For years, my transparent overlay worked flawlessly—quietly deterring casual image theft without compromising readability or usability. The concept was simple: a protective barrier placed over my images to prevent right-click saving. It was an elegant trick, subtly reinforcing the integrity of my visuals without drawing attention to itself. That is until it went too far.
As detailed in the first installment of this story, I recently uncovered an invisible flaw that had silently disrupted my blog’s usability. What began as a minor annoyance quickly escalated into a deeper issue. The overlay wasn’t just shielding images—it was obstructing text selection, preventing tooltips from appearing, and, worst of all, breaking essential interactions like clicking links. What had once been a seamless defense mechanism had inadvertently turned into an invisible wall, blocking my readers from fully engaging with my content.
Despite my attempt to learn HTML and CSS when I embarked on this blogging journey, I am far from being an expert—especially after a five-year interruption 1 that left me more rusted than refined. So, when I struggled to grasp the issue with my transparent overlay, I turned to AI for help. Surely, Copilot or Gemini would offer a straightforward, elegant solution. Yet, despite their confident responses, neither pinpointed the actual cause of the problem. And, of course, without identifying the root issue, they couldn’t provide a working solution to the bug.
If you want something done, do it yourself.Napoléon Bonaparte
The fix wasn’t obvious. No glaring error, no immediate warning sign—just a subtle shift in WordPress’s markup that had silently reshaped my protection mechanism into a usability nightmare. But with patience, observation, and a methodical approach, I traced the root of the problem: a structural change introduced in WordPress 6.0 that disrupted my setup. With this discovery, I devised a workaround to restore functionality. It worked. Technically.
A patch, but not yet a fix!
But was it truly a solution? Not really. It was a patch, not a fix. A return to an earlier state, not a true refinement. If I was going to resolve this issue properly, I had to go deeper—beyond merely restoring lost functionality and toward a well-structured, lasting solution, as suggested by Gemini. So, despite its initial failure to crack the puzzle, I placed my trust in it once more, hoping it would guide me in my quest for a proper, semantic approach that aligned with best practices—rather than simply duct-taping things back together.
While your current solution works, it’s not the most semantically ideal or robust in terms of CSS.Gemini
Decoding WordPress’s change
When I realized that my workaround essentially reverted to my old setup, I stopped. If WordPress had deliberately reshaped its code, there had to be a reason. Before forcing my overlay back into its previous form, I needed to determine whether the change introduced in WordPress 6.0 was a genuine improvement. If it was, a true fix wouldn’t just restore lost functionality—it would need to align with the new structure rather than bypass it.
Quality first—no matter how hard the fix.
Picking up where we left off, I presented my latest discovery to Gemini—hoping this time it would provide deeper insight into WordPress’s structural changes rather than merely analyzing my workaround.
“I’ve identified the root cause of the bug in my code. When I originally implemented my overlay, WordPress’s structure included an extra <div> around images. However, with WordPress 6.0, that additional wrapper was removed, altering how images are handled. As a result, my recent fix wasn’t truly an improvement—it simply reverted my code to its original state. Can you explain why WordPress made this change? How does the new approach improve image handling? And most importantly, why should I adapt to this new structure rather than reinstating the extra <div>?”
Prior to WordPress 6.0 (or even earlier with Gutenberg’s continuous evolution), the HTML output for an image block (especially aligned ones) often looked something like this:
<div class="wp-block-image size-large aligncenter"> <figure class="aligncenter">
<img src="..." alt="..." class="wp-image-XXXX"/>
<figcaption>...</figcaption>
</figure>
</div>WordPress 6.0 (and subsequent versions) aimed to simplify this, often resulting in output closer to:
<figure class="wp-block-image size-large aligncenter">
<img src="..." alt="..." class="wp-image-XXXX"/>
<figcaption>...</figcaption>
</figure>The wp-block-image class (and alignment classes) are now often applied directly to the <figure> element itself.
This shift was about more than just aesthetics—it was a structural optimization grounded in several key principles:
Cleaner, more semantic HTML: The change eliminates redundant elements, reducing the infamous “div soup” that often clutters web markup. HTML5 provides semantic elements like <figure> and <figcaption> specifically for images and their captions, making additional wrappers unnecessary. By applying the block classes directly to <figure>, WordPress ensures a more meaningful, readable structure.
Improved performance: Every extra HTML element adds to the complexity of the Document Object Model (DOM), which browsers must parse and render. Removing superfluous <div> elements:
- Speeds up parsing and rendering, leading to faster page loads.
- Reduces memory usage by streamlining the DOM tree.
- Enhances JavaScript performance when interacting with the page structure.
Across an image-heavy site, these incremental improvements can translate into a noticeable performance boost.
Better theming flexibility: With block themes gaining prominence, styling elements directly—rather than through unnecessary wrappers—simplifies customization. Instead of targeting .wp-block-image > figure, developers can now style .wp-block-image on the <figure> itself, making CSS more efficient and precise.
Alignment with web standards: Modern web development increasingly favors semantic HTML and lean markup. By eliminating redundant elements, WordPress aligns its architecture with best practices, ensuring long-term compatibility with evolving technologies.
Clearly, WordPress’s decision to streamline its image handling was an improvement. Gemini made a compelling case for embracing this change rather than clinging to outdated structure. My workaround had merely undone WordPress’s refinement—reinstating a redundant <div> rather than adapting to the more efficient, semantic approach. By restoring the old structure, I was unintentionally working against WordPress’s improvements. Keeping the extra wrapper might have restored my overlay’s functionality, but it also came at a cost:
Future-proofing: WordPress will continue refining its HTML output. Relying on a structure it has actively deprecated risks breaking my setup again in future updates.
Performance & maintainability: Reintroducing an unnecessary wrapper negates the efficiency gains WordPress has achieved.
Semantic correctness: My workaround added a redundant wrapper around a fully semantic <figure>, undermining the clarity of the markup.
Complexity: Instead of adapting my CSS to the new structure, I was layering unnecessary elements onto WordPress’s revised design.
A true fix wouldn’t just restore my overlay—it would align with WordPress’s new approach, ensuring lasting functionality rather than a temporary patch.
Misplaced trust, familiar failure
Gemini had already failed to fix the bug in the first place—a flaw I have dissected in my previous post. Yet, I asked for its help again. I should have known better. If it couldn’t provide a working solution back then, how could it possibly improve upon the issue now—especially while adhering to WordPress’s refined structure?
The most robust, semantically correct, and generally recommended way to overlay something precisely on an image is to make the image’s immediate semantic container (the <figure> element in this case) the positioning context for the overlay. This ensures the overlay directly matches the image content, independent of outer WordPress block wrappers or captions.Gemini
Despite all the warning signs, I placed my trust in AI once more. I naively believed that this time would be different—that my insights, my careful analysis, would steer Gemini toward a real solution. It had everything it needed: the broken code, my workaround, the structural change introduced in WordPress 6.0, and the full record of our conversation—all the failed attempts laid out before it. Armed with context, surely it wouldn’t repeat its past mistakes.
Long story short: it failed.
Oh, naïve indeed. First, Gemini simply recycled its own mistakes, dressing them up as fresh insight. It confidently proposed the same code that had already failed—again—as if restarting the conversation would somehow rewrite reality and magically make broken logic work. The flaw had been there from the start. Perhaps the convenience of picking up where we left off wasn’t such a luxury after all.
Its singular focus remained unchanged: ensuring the protective overlay perfectly aligned with the image—without covering captions. It fixated on avoiding overlap with the caption, treating it as the core challenge—despite my repeated assurances that this was irrelevant. The real issue, the one that had broken my protection mechanism, was far more significant. Yet, instead of addressing the deeper flaw, Gemini remained locked in its obsession, refining solutions for a non-existent problem while ignoring the actual bug.
As mentioned above, Gemini had made its stance clear from the start: the extra <div> was unnecessary, an outdated remnant that contradicted WordPress’s push for cleaner, more semantic HTML. It lectured me on best practices, explaining how removing redundant wrappers aligned with modern development standards. And I listened. I trusted its logic. Until it broke its own rules.
Faced with its own flawed solution, Gemini did exactly what it had warned me against—it reintroduced another wrapper to fix the very problem it had failed to address. The irony was staggering. Its conviction had been absolute, yet when its approach collapsed, it resorted to the same tactic it had previously dismissed. That was when I realized: there was no logic, no intelligence—just a cycle of confident proclamations and hollow assurances. I had been chasing reasoning that didn’t exist. It was time to stop blindly trusting.
In the end, Gemini admitted defeat. It had run out of solutions, conceding that the only viable path forward was my own workaround—the very approach it had spent so much time dismissing. After all its confident assurances, and all its theoretical best practices, it came full circle, advising me to reinstate the extra <div> it had initially deemed unnecessary. No elegant fix, no refined solution—just a reluctant endorsement of the method I had devised on my own.
Just when I thought Gemini asking me to give up was the peak of its failure, it proved me wrong. When I returned later—this time with the solution it had failed to find—it exposed a new level of incompetence. Not only did it fail to comprehend the fix, but it started hallucinating entirely new code, twisting logic into yet another flawed approach. I had expected a moment of validation—an acknowledgment that the solution had been there all along. Instead, Gemini doubled down, proving that it hadn’t just failed to solve the problem—it couldn’t even recognize the answer when it was handed to it.
Gemini failed. Big time.
When all else fails—debugging solo again
Gemini had failed. Copilot hadn’t cracked it either. And learning HTML and CSS properly—the long, structured way—wasn’t an option. Not that it wasn’t on my to-do list. Quite the opposite—mastering these skills had been part of my blogging ambition from the very beginning, seven years ago 2. But time had never been on my side, and it certainly wasn’t now. Months, possibly years, to gain expertise? Unrealistic. I needed a solution now.
I may have wasted time chasing AI-generated solutions. I may not have fully grasped every aspect of the code. But at least, I had my workaround—imperfect, yet functional. I also identified the structural shift introduced in WordPress 6.0, a key factor in understanding the contrast between my broken implementation and the correct approach. And, to give credit where it’s due, Gemini had at least provided one crucial insight: the .first container was failing to inherit its height from the image it was meant to overlay.
Instead of approaching the problem like a seasoned developer—mapping out logic, predicting outcomes, and debugging with precision—I took a far messier route: brute force. Trial and error. No grand theory, no structured method—just a relentless, almost stubborn determination. I cycled through countless HTML variations, tested permutation after permutation, tweaked configurations, adjusted variables, and experimented with every possible combination, hoping that somewhere in the chaos, the right structure would emerge.
After endless trials, the answer finally emerged.
I wouldn’t dare call it a Eureka! moment—not after the chaotic, brute-force approach that got me here. In fact, when I reveal the actual solution, you’ll see just how absurd this entire journey really was. But in the end, what mattered wasn’t the method—it was the result. Against all odds, I had found a fix that truly aligned with WordPress’s refined structure. No forced workarounds, no reverting to old habits. Just a proper solution. And for that, I’m glad I didn’t give up—or settle for less.
Breaking down the problem—and the solution
Before I can explain the issue, I need to lay out all the pieces of the puzzle first. At the heart of my implementation was this reusable block:
<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 rights reserved" src="URL OF THE TRANSPARENT IMAGE HERE">
</div>This worked seamlessly with WordPress images formatted like this:
<div class="wp-block-image alignleft">
<figure>
<img src="someimage.jpg" alt="" width="100" height="100"/>
</figure>
</div>However, WordPress 6.0 introduced a major structural change. Instead of wrapping images inside an extra <div>, it streamlined the markup to:
<figure class="wp-block-image alignleft">
<img src="someimage.jpg" alt="" width="100" height="100"/>
</figure>Previously, WordPress wrapped images inside an extra <div>, which allowed my .first container to easily inherit the image’s dimensions. However, when WordPress 6.0 removed that wrapper and applied styles directly to the <figure> element instead, my protection mechanism broke. The problem wasn’t in the overlay itself—it was in the way my reusable block handled styling. Following my original instructions, I moved all styling to the outer <div> instead of leaving it within <figure>. This had an unintended consequence: the transparent overlay image could no longer reference the correct dimensions because that data had been moved out of the element it relied on.
As a result, my .second image—meant to act as a protective layer—failed to properly inherit the size of the underlying image, breaking the functionality entirely.
The solution, when it finally emerged, was almost absurd in its simplicity: leave the styling where WordPress intended it—inside <figure>—rather than shifting it to the enclosing <div>. By keeping the class and alignment information within <figure>, my overlay regained its ability to correctly inherit the image’s size. No more broken dimensions, no more misplaced styling—just a clean implementation that aligned perfectly with WordPress’s refined markup.
The final template became even simpler:
<div class="first">
<!-- PASTE THE ENTIRE HTML COPIED FROM THE IMAGE BLOCK HERE. -->
<img class="second" alt="All rights reserved" src="URL OF THE TRANSPARENT IMAGE HERE">
</div>No need to manually move styling anymore—WordPress already does it properly. This not only restored functionality but made the implementation faster, cleaner, and fully compliant with WordPress’s new structure.
The irony is striking—AI, with all its supposed expertise, couldn’t see the solution 3, yet it was right there all along. And in the end, brute force, intuition, and perseverance beat the machine. So, credit where credit is due—WordPress for refining its code, and me for not giving up until I found the right solution.
1 As longtime readers of this blog may recall, everything CogitActive-related was put on hold following that fateful summer of 2020—a turning point detailed in my post 100th post – a bittersweet celebration!. ^
2 While seven years had passed since I first set out to master these skills, not all of them were available for this pursuit—see footnote above. ^
3 I gave Copilot the opportunity to exercise its right of reply. It responded AI relies on pattern recognition and structured logic, but debugging requires contextual reasoning—something it lacks. Without the ability to truly experiment, observe failure firsthand, and course-correct intuitively, AI often misidentifies the real issue, leading to repeated errors rather than genuine problem-solving.
^