I broke an Elementor site on purpose, then built a tool to find the bugs

The night I broke my own site

I'm 53, I work in a factory, and in the evenings I build things in vanilla JavaScript.

Lately I've been looking at freelance WordPress jobs. Almost every one of them says the same thing: "Elementor site, layout is broken, fix it."

So I did something a bit crazy. I took an empty test site, installed Elementor, and asked an AI to break it for me — 5 hidden CSS bugs, packed into an encoded script so I couldn't just read the answer.

Then I tried to find them.

It was humbling. The page looked wrong, but the console said nothing. Of course: CSS doesn't throw errors. A bad rule is still a valid rule, so the browser applies it silently. That's exactly why clients say "everything moved and I don't know why."

I found the first bug the slow way — DevTools, Styles panel, unchecking rules one by one until I saw it:

.elementor-section, .e-con { margin-right: -60px !important; }

Twenty minutes for one line. I thought: there must be a faster way.

So I built one: CSS hunt

🐞 BeeLadybug is my zero-dependency debugging overlay. You paste one line in the console and it attaches to any page — WordPress dashboards, Elementor pages, mobile viewports. It already showed element size, classes, display type, FPS and memory.

Version 0.5 adds a new mode: CSS hunt (press F6).

When you hover an element, it tells you what's wrong with it:

• !important rules that match the element, and where they come from (<style> inline or the stylesheet URL)
• Overflow causes: which element actually leaves the viewport, plus negative margins
• Invisible text: color: transparent, opacity: 0, or text the same color as its background
• Click blockers: what sits on top of the element's center, including fixed ::before / ::after on html / body
• Stretched images: natural ratio vs rendered ratio, when object-fit is fill

Press S to scan the whole page. Click a line and the element gets a red outline.

The hard part: telling the truth without noise

My first version was technically right and practically useless.

One card overflowing the screen produced ten red lines: the card, its article, its p, its h2… All "overflowing", because they inherited it. A fixed overlay blocking clicks? One warning per element underneath it.

A real developer doesn't want ten alarms. They want the culprit.

So the scan now:

1. Reports the cause, not the containers. An ancestor is skipped if a descendant overflows by the same amount (±2px).
2. Groups by cause. Instead of 12 lines you get:

▾ body::after blocks clicks on 12 elements
    div.elementor-element-629ef32
    img#1301
    summary.elementor-element-3925463
    …

1. Separates bugs from info. Red = bug. Grey = info, like unreadable sheet: fonts.googleapis.com (cross-origin stylesheets can't be read — that's a browser rule, not a problem on the page).
2. Keeps the log calm. Hover and DOM-mutation lines are hidden unless you turn on verbose mode (F3). Each issue is logged once per element every 5 seconds. Press P to pin the panel on an element and read it in peace.

The real test

The demo page bugs are easy — I wrote them. The real test was the broken Elementor page, with Elementor V4 "atomic" widgets, Google Fonts, Altervista ad scripts and all the usual mess.

Result: CSS hunt found the click blocker, the negative margin overflow, the invisible button text and the stretched image on a live page I didn't build the bugs for.

Try it

Open any page, press F12, paste this in the console:

import('https://cdn.jsdelivr.net/npm/bee-ladybug@0.5.3/src/index.js')
  .then(({ BeeLadybugCore, WebDOMAdapter, CSSAdapter }) => {
    const bee = new BeeLadybugCore();
    new WebDOMAdapter(bee, { root: document.body }).attach();
    new CSSAdapter(bee).attach();
    window.bee = bee;
  });

Then press F6, hover, and press S.

No build step, no framework, no dependencies. Just vanilla JavaScript.

What I learned

• CSS bugs are silent. The console won't help you. You need to look at computed styles and geometry.
• The right answer is not enough. A debugging tool must point to the cause, or it's just another wall of text.
• Breaking things on purpose is the best teacher. I recommend it to anyone who wants to do WordPress fixes for clients.

I'm still learning. If you try CSS hunt on a broken page and it misses something, tell me in the comments — that's how the next version gets better.

🐞 npm: bee-ladybug

Comments

[Rishabh Mishra]

Breaking things on purpose is a great training loop. Nothing teaches like a bug you planted yourself. The design decision I would steal is reporting the cause instead of the containers: ten red lines for one overflow is how tools teach people to ignore them. One idea to consider: grouping by stacking context too, since z-index surprises are the next classic in this genre.

[Antonio]

Thanks! "Ten red lines for one overflow is how tools teach people to ignore them" — that's exactly what pushed me to group by cause in 0.5.3.

Stacking context grouping is a great idea. z-index surprises are the classic "why is this behind that?" bug, and the cause is usually a parent with transform, opacity or position that silently creates a new context. I'm adding it to the list for the next version. Thanks for the push!

[Rishabh Mishra]

Glad it resonated. If it helps, the check I would run is a walk up getComputedStyle looking for anything that creates a context: transform, opacity under 1, filter, will-change, or a positioned element with z-index. That gives you the culprit node in one pass, and it fits the cause-grouping model you already have.