I already had the solution on the screen. Twice, actually.

Two small floating logo/search buttons on my site stayed visible all the way to the footer. Their .blocco-nav-fluttuante used position: fixed, with top: 45px and left: 20px. No JavaScript moving them around. They simply stayed there.

So why couldn't my central search and categories bar work the same way?

That was my point. Getting my AI assistants to stay focused on it took considerably longer than writing the CSS.

In my previous article, I covered the homepage rebuild of SPC – Super Play Combo, my WordPress games portal. This time, the important part isn't a new engine or a clever architecture. It's the simple solution I kept asking for.

Here is the fix—not three sections later

I wanted a rounded bar, slightly detached from the top and sides, with games scrolling underneath it. Visible right down to the footer. I showed Poki as a visual reference for that behavior, not as a source of code.

These are the two CSS rules that delivered it on the Arcade page:

.barra-fissa-spc { position: fixed; top: 12px; left: 12px; right: 12px; margin: 0 auto; max-width: 540px; border-radius: 22px; } .contenitore-arcade-spc { padding: 150px 10px 10px 10px !important; }

Fixed positioning from the first paint, plus space already reserved underneath. That was the solution for the bar.

The bar stayed in its existing HTML location. Its controls, IDs, event handlers, URLs, and category logic stayed intact. No separate external file. No engine rewrite. No rebuilding the categories just to make a bar float.

A few CSS declarations. A much longer conversation.

Why the two little buttons had the right idea

sticky and fixed aren't interchangeable. In my layout, a sticky bar was constrained by its containing block. It didn't stay visible through the footer the way I wanted.

The little floating buttons already demonstrated the alternative: anchor to the viewport with fixed.

For the central bar, top: 12px creates the gap above it; the side offsets and maximum width keep it centered; the radius rounds all four corners. The games can scroll behind it, including through that small gap above.

Because fixed elements don't occupy normal-flow space, the container needs room at the top. The final value here was 150px, not the earlier 135px trial. That keeps the title, description, and first games clear of the bar initially. It's a value for my layout, to check at different widths and with the WordPress admin bar—not a magic number for every site.

The JavaScript detour we didn't need

The earlier spostaBarra() function relocated the bar into the body on DOMContentLoaded. Moving a visible element after rendering was an avoidable layout-shift risk. A Puzzle report showing the whole #page displaced made that worth investigating.

The answer wasn't another relocation strategy. It was to stop relocating it:

function avvia() { // spostaBarra(); osservaGioco(); }

osservaGioco() still handles visibility when opening a game. Removing the move didn't mean throwing away useful behavior.

During troubleshooting of the optimized styles, we also added this as the first CSS rule:

.spc-css-guard { --spc: 1; }

That was a debugging precaution, not a diagnosed universal LiteSpeed fix. The layout solution remained fixed plus reserved space, with !important on my container padding to keep it applied.

My AI assistants were helping. Enthusiastically. Elsewhere.

The discussion kept wandering into animation, visual styling, layout shifts, and changes to the game engine. Meanwhile, I kept returning to those two little floating buttons.

I knew the behavior I wanted. I was using AI to implement it, not asking it to replace the goal with something more complicated.

I also did my part to prolong the adventure: undoing and reapplying changes whenever PageSpeed moved. Apparently, my afternoon needed a second source of stubbornness.

Still, this was a satisfying little vindication. I didn't need to name every CSS property to recognize that the working example was already on my own page.

One separate issue, not a reason to rebuild the bar

The game grid had its own loading problem. An intermediate Arcade report showed CLS 0.120: 0.102 attributed to pagination and 0.018 to the grid.

The separate fix reserved responsive space for the first 60 cards while JavaScript populated the grid. Once filled, the waiting class was removed, allowing filtered results and shorter final pages to use their natural height.

That mattered for stability. It wasn't part of making the search bar float, and it didn't require reinventing the bar.

The result—and six categories still waiting

The later Arcade mobile lab report reached 99 Performance, with FCP and LCP at 1.4s, 30ms Total Blocking Time, and CLS 0.017. Accessibility, Best Practices, and SEO were 100.

Not a promise of zero CLS everywhere, and not a claim that the bar's CSS alone produced the whole score. But the intended behavior worked, and the layout was much steadier.

Now I'm saving the stable version before carefully updating the six remaining categories. First, this article. Even debugging deserves an intermission.

Have your AI assistants ever confidently complicated something you already knew could be simple? And have you solved a floating-bar or layout-shift problem this way? Tell me in the comments.