BeeLadybug 0.5 加入 CSS hunt 偵錯模式
I broke an Elementor site on purpose, then built a tool to find the bugs
BeeLadybug 0.5 加入 CSS hunt 偵錯模式,可檢查元素匹配的 !important 規則及其來源,並定位溢出、不可見文字、點擊遮擋和拉伸圖片。按 S 可掃描整頁,結果按成因分組,避免把受影響的容器逐項重複列出。作者在實際 Elementor 故障頁面上用它找出點擊遮擋、負邊距溢出、不可見按鈕文字及拉伸圖片。
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:
-
!importantrules 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/::afteronhtml/body -
Stretched images: natural ratio vs rendered ratio, when
object-fitisfill
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:
- Reports the cause, not the containers. An ancestor is skipped if a descendant overflows by the same amount (±2px).
- 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
…
-
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). -
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. PressPto 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
來源:DEV Community · dev.to
