Previously on the CogitActive Saga:
I had finally reached a blue that was close enough to call a victory. But the moment I applied it, the button’s text became unreadable.
In my previous post — When the shadow refuses to fade — I chronicled how a simple goal, recoloring an external SVG icon so it matches the blue of my comment form’s Submit button, turned into a long, technical chase. Because the SVG is loaded externally, I couldn’t edit its internal styles, and this simple detail dragged me into a labyrinth of filters, false hopes, and AI‑generated nonsense. Eventually, through trial‑and‑error and using the DevTools Eyedropper to measure the actual output color, I managed to coax the shadow into the blue I wanted — almost, #2a3f8c instead of the intended #253f8c. But the victory collapsed under accessibility contrast standards. The method that produces the right color breaks the icon in another way, making the button’s text unreadable. And the post ends with my reluctant acceptance: the grayscale(1) filter had to stay.
Accepting defeat — and, to be fair, acknowledging that the grey shadow had a certain understated elegance — I moved on to preparing the post for publication. My workflow is always the same: copy the draft from Word into Notepad to strip away any lingering formatting, keep both windows open side by side so I can still see the styled version, then open Gutenberg and begin rebuilding the post block by block in a Custom HTML block. It’s a slow, meticulous process of pasting plain text and reapplying the structure by hand, matching each tag to the original intent. Before hitting Schedule, I always read everything one last time, scanning for typos, misaligned tags, or anything that might break the layout. But this time, as I reached the section describing the CSS filters, I stopped cold at a line I had typed almost absent‑mindedly earlier:
invert() — Inverts colors, creating a photographic negative.
My original problem was simple: the text on my button is darker than the light‑blue background that appears on hover, and the filter I was using darkened everything — text and background alike — which inevitably destroyed the contrast. But when I use my preferred blue, #253f8c, I normally pair it with white text precisely to meet accessibility standards. So why not flip the logic? A photographic negative. That should fix the contrast issue.
But even better. As alluded to, I couldn’t match my blue perfectly — the color‑blind AIs had unanimously declared it “impossible” — but the CSS Color Filter Generator (external link) claimed it could produce an exact match. Its only limitation was that it always began with brightness(0) saturate(100%), forcing the starting point to pure black… which, of course, erased my text. But if I made the background black myself, then applied only the rest of the filter chain, I could bypass that constraint entirely. Suddenly, it all clicked. A workaround. A loophole. A tiny “Heureka!” moment. Maybe, just maybe, this could work.
The first step turned out to be a two‑step maneuver of its own. Inverting the colors was trivial — just filter: invert(1) — but getting a clean black background was another story. I wrestled with it a bit before finally turning to Copilot for help (please, don’t judge me). It wasn’t a one‑shot solution; more of a back‑and‑forth where its suggestions and my logic slowly converged toward something workable. Together, we pieced the rest of the filter chain into shape, and I ended up with this:
filter: invert(1) grayscale(1) contrast(200%);I genuinely thought the hard part was behind me. I was staring at a perfectly clean black‑and‑white button — black background, white text — exactly the starting point the CSS Color Filter Generator always assumes. So I opened it, typed #253f8c into the target field, and clicked Get Filter!. The output was flawless: the Real pixel read rgb(37, 63, 140), a perfect match to my intended blue. Confident, I copied the generated filter into Notepad, removed its mandatory brightness(0) saturate(100%) prelude, and replaced it with my own invert(1) grayscale(1) contrast(200%). Then I applied the filter (using DevTools) to admire the result. And… what was that? That wasn’t blue — certainly not my blue. The supposedly perfect match had shifted into something else entirely, and I was left wondering where the discrepancy had crept in.
Filter: invert(1) grayscale(1) contrast(200%) invert(17%) sepia(45%) saturate(3166%) hue-rotate(214deg) brightness(98%) contrast(89%)I hadn’t expected that at all. For a moment, I just stared at the screen, unable to make sense of it — not shocked, exactly, but with my rational brain refusing to engage. So, I blamed my own code. Maybe my invert(1) grayscale(1) contrast(200%) wasn’t producing a “true” black after all. To check, I opened the DevTools Eyedropper and compared my result to the generator’s usual starting point, brightness(0) saturate(100%). Aside from the obvious difference — the generator’s version wiped out the text — both produced a perfect #000000. No deviation, no hidden tint, nothing to explain the mismatch. And that’s when the late‑night version of me took over — the one who always ends up “Gutenberging” posts far too late after a draining, vampirising day at work. In that foggy state, a strange idea surfaced: could the filter somehow be “contaminated” by the presence of the white text?
Fortunately, I didn’t go down that path; I had the presence of mind — la présence d’esprit, as we say in French — to test the full filter code generated by the tool before chasing any new theory. And I could not believe what I saw. The result was nowhere near the claimed perfect match. How could rgb(37, 63, 140) suddenly not be rgb(37, 63, 140)? No matter how I checked it — RGB, HEX, even sampling the pixel directly — #253f8c was not #253f8c. And yet the tool was confidently giving me the filter chain supposedly producing that exact color. Something wasn’t adding up. What was I missing? That’s when I finally saw it — not in the main window, but tucked just below the fold, only visible once I scrolled down a little. The generator had quietly added a line under the output:
Loss: 4.9. This is close enough.
Close enough? Clearly, that tool doesn’t know me 1. I had assumed the “perfect match” was literal, not an approximation wrapped in reassuring language. But there it was: a nearly five‑point loss, openly acknowledged yet easy to miss unless you happened to look in exactly the right place. Suddenly, the mystery wasn’t a mystery at all. The generator wasn’t giving me #253f8c — it was giving me something near #253f8c and calling it a day. And for my use case, “close enough” was nowhere near good enough.
There was a trick, though. You can click the Get Filter! button again… and again… and again. Each click generates a new attempt, a new approximation, a new “close enough.” So I clicked. And clicked. And clicked. Until, finally, I saw it:
Loss: 0.0. This is a perfect match.
Except, once again, we didn’t share the same definition of “perfect.” The resulting color wasn’t #253f8c but #253f8d — one digit off, but enough to make my eye twitch. It was “PERFEDT,” not PERFECT. Yes, a single letter matters. A single digit matters; I’ll spare you the other spurious examples 2. But here’s the real catch: that supposedly perfect filter didn’t just miss the color; it also damaged my white text, turning it into a dull, washed‑out purple. The button looked… well, not pretty.
In the end, I had to accept what I had been resisting from the start: the grayscale filter stays. After all the experiments, the approximations, the “perfect matches” that weren’t, and the filters that mangled my carefully chosen white text, the original grey shadow suddenly didn’t look so bad. In fact, it had a quiet elegance to it — consistent, readable, and, most importantly, reliable. I may not have won my battle for #253f8c, but at least the button works, the contrast holds, and the whole thing behaves predictably. Sometimes the clean, simple solution is the one you tried to replace in the first place.
But I did allow myself one small victory. The button that triggers the whole mechanism — the one readers click to request comments to reopen — also reveals a tiny mini‑comment field. And unlike the doorbell icon, that little form ends with a real button. A proper HTML button. No external SVG. Just a normal element I could finally style without acrobatics. So I gave it the blue it deserved:
.form .button { background: #253f8c; }And, in a final act of quiet rebellion, I even disabled a lingering grayscale(0.5) filter. A tiny change, barely noticeable in the code, but deeply satisfying. The other shadow may stay, but this last button — the one that actually submits the request — gets to wear my perfect blue.
And, with this, I switch the widget from Disabled to Enabled and…
“Houston, we have a problem.”
To be continued…
1 Quality is not negotiable for me. As I’ve written elsewhere, I don’t subscribe to the 80/20 rule — not when it comes to my work, not when it comes to this blog. I grew up with “Un travail bien fait rend heureux” etched into my habits, and I’ve carried that mindset into everything I do. “Close enough” may satisfy a tool, but it doesn’t satisfy me; I chase precision the way others chase speed, because doing things right the first time is the only approach that makes sense to me. ^
2 I have given you the harmless version; other near‑matches could easily produce real words with very different — sometimes very unfortunate — meanings. ^