Through CSS confusion toward insight

Introduction

Where to begin? Perhaps at the moment I tried to pick up the thread of my interrupted post, resuming the work I had abandoned mid‑sentence. But you already know that part, I told it (all) in the previous post: the courtroom drama, the unresolved verdict, and the Hydra metaphor. So what will this post be about? The detailed account of what really happened. A chronicle, not a metaphor. But before diving into the blow‑by‑blow, I need to set the stage.

There I was, determined to resume and finish that interrupted post, no verdict, but a choice nonetheless: padding‑left. Or margin‑left? A choice, maybe; still, not convinced, my mind kept flipping back and forth, like ripples across a lake: less frequent now, but still there.

I had carved out a block of time over the weekend to draft the post. Normally, weekends are sacred — reserved for family, not for CogitActive. But the previous week had swallowed my evenings with extra work, leaving no room for writing. Work first, right? So I asked my family for a small exception, a little window to catch up. They graciously offered it, and I thought that would be enough. After all, most of the post was already written back when the supposedly concluding post was interrupted. All I needed was to implement the CSS, confirm it worked, and move forward. Simple. Or so I believed.

But plans have a way of collapsing. That weekend window I had carved out slipped away under the pressure of unexpected demands. Family emergencies took precedence — family first, right? — and the time I thought I had secured vanished. The following week offered no relief: Monday, Tuesday, Wednesday… packed from start to finish. And yet the deadline loomed. As regular readers know, I’ve published a new post every Thursday without interruption since September 6, 2018. That streak was non‑negotiable.

My four‑post buffer, once meant to shield me from weeks like this, had long since been depleted. Despite repeated attempts to rebuild it after the fateful summer of 2020, it never held. Which meant only one thing: by Thursday morning, a post had to be ready — no matter what. That left only one option: once the day’s work was done and the family was asleep, I had to tend to the third wheel of the carriage: CogitActive. Don’t ask about the fourth wheel — me. That one’s long gone.

So there I was, exhausted from a long day with no weekend recovery, late at night, starting again from the beginning. Hoping I could finish in time to publish the post — and maybe, just maybe, steal a couple of hours of sleep.

Hurdle #1: 1+2=3

The code felt like a no‑brainer. I had seen it millions of times — and I mean that literally, not as an idiom. My obsession with padding and margin had lasted for months, and every time I asked an AI (whether Copilot or Gemini, in whatever mode I set them), it handed me the same snippet over and over:

section section {
  padding-inline-start: 10%;
}

section section section {
  padding-inline-start: 20%;
}

section section section section {
  padding-inline-start: 30%;
}

section section section section section {
  padding-inline-start: 40%;
}

Admittedly, in this series, I had leaned far too heavily on AI for CSS questions. However, I had learned the hard way that, no matter the mode (from quick — excellent for editing, by the way — to Think Deeper), Copilot made plenty of mistakes. It doesn’t really think. So I wasn’t about to drop its code straight into the stylesheet of my child theme and call it a day. I needed a safer, easier environment to test. And again, I wanted to know how % will behave.

I had previously experimented with DevTools, but only section by section — never across a full post. This time, I turned to the Customizer of my Twenty Seventeen theme. For those unfamiliar with this relic from before Full‑Site Editing (the latter was introduced in WordPress 5.9), the Customizer offered a simple interface with live preview. One of its features, “Additional CSS,” lets you override the current theme with your own statements. Quick, easy, and perfect for testing.

And then the first issue revealed itself. The indents weren’t stepping forward in a regular rhythm. Instead of a steady shift — 10%, then 20%, then 30% — the spacing was ballooning. The second level didn’t land at 20%, but at 30. The third wasn’t at 30%, but at 60. What should have been a neat staircase was turning into a lopsided climb, each step wider than the last.

“Why?”

My first instinct was to blame % and inline-start. I tried padding-left instead of padding-inline-start. Same result. Margin? Same. I swapped % for rem. Still the same. Of course, I wasn’t thinking clearly. I was tired — literally, from the long day, and figuratively, from this never‑ending nightmare about padding versus margin. Or maybe I had spent too much time with AIs, and their sloppy habits of not actually reasoning ¹ were rubbing off on me.

My second thought turned to the selector itself. Months earlier, I had stumbled across section > section in a Stack Overflow thread ². At the time, I did a quick — far too quick — search to see what it meant. In truth, I asked Copilot, and it explained that this CSS selector “selects any <section> element that is a direct child of another <section> element.” Back then, I dismissed the approach. Not only did I already have my selectors (right?), but I was also convinced the other would only apply to my H3 sections and not to deeper nesting. That assumption was a mistake. A proper search — the CogitActive way — would have taught me better. Especially to notice one crucial word: direct. But let’s not get ahead of the story.

Anyway, I did remember from my shamefully quick search that, unlike section > section, the selector section section targets any <section> nested inside another <section> — at any depth. That shaky “info” was enough to push me into another attempt. On the basis of yet another wrong assumption, I convinced myself that the indents were stacking. My flawed reasoning went like this: if section section section applied the intended indent to H3, while section section applied to them all (H2 and H3 alike), then the H3 would inherit both. Two plus one equals three.

I could have stopped there, but I asked Copilot, “Why?” Wrong. I know. But, oops, I did it again. It explained: “Paddings are applied on each element individually, so nested paddings accumulate visually.” And then it offered me “ways to get the behavior [I] likely want.” One suggestion was to apply indentation only to elements at a given depth, not to every ancestor. This, it claimed, would produce a fixed indent per level (non‑cumulative):

section {
  padding-inline-start: 0;
}

section > section {
  padding-inline-start: 10%;
}

section > section > section {
  padding-inline-start: 20%;
}

Before trying the child‑combinator approach — and given the nonsense of the other suggestions — I dared to ask: “In other modes, Copilot kept suggesting the familiar pattern — 1  rem, then 2  rem, and so on. I hadn’t expected this effect at all. Can you explain? And which is better — section section or section > section?” Of course, it didn’t answer about its counterparts’ CSS code, but it did explain that I didn’t need all the section section section… selectors. I could just use section section with 1 rem, and this would apply my staircase the way I wanted to all nested sections. Or — and it advocated this as the better approach — for “precise per‑level, non‑cumulative spacing,” I should use:

section > section {
  padding-inline-start: 1rem;
}

section > section > section {
  padding-inline-start: 2rem;
}

section > section > section > section {
  padding-inline-start: 3rem;
}

section > section > section > section {
  padding-inline-start: 4rem;
}

So I tried it. And nothing happened. No indent at all. I told Copilot, but by then my brain was barely functioning — half asleep, half fried. That’s when the “Quick diagnosis (most likely causes)” game began: a back‑and‑forth that only drained what little energy I had left. Like someone who knows nothing about the subject — which, at that hour, was partly true — I went through them one by one. Even when I knew they were nonsense, I still tested them. Patiently. Obediently. Like a customer stuck on a service line, following every scripted step. Or, more honestly, like a zombie.

When we had exhausted them all — the five “likely causes” from the first batch — Copilot came up with a new list: “Likely causes (ranked, with how they make your rule fail).” I didn’t test them all this time, because one rang a bell: “Most likely the elements you expect to be direct children are not actually direct children in the DOM (so the child combinator > doesn’t match).” Remember the importance of the word direct? My brain jolted awake for a brief moment. I suddenly recalled my drafting about how to implement <section> in Gutenberg, along with the odd detail I had noted back then: Gutenberg was slipping in an extra <div>.

That was the missing piece. Now, I won’t unfold this part of the story here (not even the 1+2=3 explanation), because this hiccup doesn’t just raise a minor issue — it challenges my entire choice of selector. And that deserves its own space. I’ll tell that chapter separately, in another post.

Hurdle #2: 23.594 ≠ 22.351

There was one nagging issue I couldn’t ignore. You might recall from my tangled post about CSS units the claim I once made: If I go with padding‑left, % remains viable. If I choose margin‑left, it doesn’t. Here’s the crux of it:

% measures length relative to the parent’s width, making it naturally responsive — containers expand or shrink, and the indentation adjusts accordingly. That elegance works beautifully across different screens, sparing the need for media queries. But if the parent’s width shifts from one nested section to the next, the indent shrinks progressively, breaking the clean staircase I wanted. That was the very approach I had previously rejected.

With padding-left, the content is nudged inward while the box itself holds its full width. The parent container stays stable, so % keeps referencing the same width at every level. With margin-left, though, the box is shoved outward. The container’s right edge doesn’t move, so each nested section collides with that wall, and the available width shrinks. The deeper the nesting, the narrower the section becomes.

In short, padding preserves the reference width; margin erodes it. Which means % thrives with padding, but falters with margin.

Now, I didn’t choose padding over margin for this reason (the real explanation will come in the next post). Yet I can’t escape the thought that the distinction above may have tilted my decision — not deliberately, but quietly, beneath awareness. It lingered in the background like an unseen current, nudging me along even as I believed I was steering freely.

Anyway, there I was, finally with cumulative indentation under control (see previous section). The staircase was back, but something still refused to align. My column width should have remained constant, and yet the spacing between my H3 and H4 was off. Numbers that should have matched didn’t. A discrepancy, small but undeniable, gnawed at the edges of my layout.

I pressed on, asking Copilot why the indents between my H3 and H4 refused to match. Its reply came back with the usual confidence — or at least, that’s how my sleep‑deprived brain received it: the uneven offsets, it claimed, were not the fault of the selectors but of the DOM itself, with margins, wrappers, or computed inline‑sizes conspiring behind the scenes. It even offered a quick checklist.

And yet, dutifully, I went through each point: no stray margins, no overriding rules, no hidden wrapper depth, no ancestor with display: contents. All clear. The trail seemed to lead back toward the selector itself — a rabbit hole I had already spent most of the night exploring. But I forced myself to redirect:

“Leave the selector aside; the real concern is the padding — 23.594 px versus 22.351 px.”

Copilot’s next answer was short and sharp: those tiny differences, it explained, came from how percentages are computed and rendered. % is resolved against the containing block’s inline‑size, and the final value can differ slightly between elements because of subtle differences in width or because of subpixel rounding in layout. The longer explanation followed: browsers calculate with floating‑point values, then rasterize to device pixels according to devicePixelRatio. That process produces fractional values like 22.351 px and 23.594 px. Small upstream variations ripple down into these decimals. Honestly, that was all Greek to me — some technical mumbo jumbo I didn’t really understand — but the gist was clear enough: rounding quirks in the browser pipeline were behind the mismatch.

And so I trudged through another “quick checklist,” this one even longer and more irrelevant than the last. None of the points shed light on the discrepancy. Still, I checked them one by one, only to circle back to the same conclusion: there should be no difference. No margin, no border. Every section, from the top‑level H2 down to the nested H4, should measure the same 524.319 px in total. Why H4 resolved to 22.351 px instead of 23.594 px remained a mystery.

The cause is almost certainly sub‑pixel rounding differences in the browser pipeline.Copilot

Then came another list: precise checks, diagnostics, and “immediate fixes.” This time, I refused. My night was already lost, and I still had a post to draft and publish. Besides, those so‑called “immediate checks” required running complex code in DevTools — code I didn’t understand. And that, I will never do.

That’s when I gave up on the decimals and turned to words, drafting the Hydra metaphor post instead.

My duh moment

Looking back, though, I have to admit that post was more filler than true capture — a way to keep the Thursday streak alive rather than a piece that did justice to the struggle. The real chronicle, the one that lays bare the details and finally makes sense of it all, is the post you’re reading now. Or more precisely, what unfolded the following day, after a short night of sleep, sort of.

I opened a fresh conversation with Copilot — not a follow‑up (you know I avoid logging in), but a brand‑new one. I didn’t begin with the decimals (22.351 px vs 23.594 px); instead, I asked about selectors. I wanted to solve that first issue first. Copilot promptly suggested a new way to target my nested sections, but I didn’t follow up on it because one of the snippets it proposed caught my attention:

section section { padding-inline-start: 1.5rem; }
section section section { padding-inline-start: 3rem; }
section section section section { padding-inline-start: 4.5rem; }

I knew this wouldn’t work. More precisely, I knew it would indent by 1.5 rem, then 4.5 rem, and then 9 rem — not the neat 1.5, 3, and 4.5 rem progression it claimed. I pointed this out and asked why it behaved differently than described. Copilot’s first answer made no sense to me: “A nested child’s padding is applied inside the child box, so visually you see the parent’s padding plus the child’s padding — they don’t cancel or replace each other.”

I asked for clarification, and it elaborated: “If the parent has padding-inline-start: 1.5rem and the child has padding-inline-start: 3rem, the visual offset from the column edge will be roughly 1.5rem + 3rem because both paddings are applied in sequence.” Still, I wasn’t connecting. Maybe my brain wasn’t as rested as I thought. In my understanding, with padding (and box-sizing: border-box;), the section’s width should remain stable, so the padding would start from the left border of the column.

So I did what I should have done from the very beginning: I applied borders to my sections. And there it was, plain as day. The borders confirmed what the background colors had already hinted: the nested sections weren’t taking the full column. The parent’s padding was effectively “out,” not contained. The sections were literally nested, and the parent’s padding seemed to be pushed outward — background color and all — as if I had used margin instead.

I asked again: “I don’t understand. I thought padding, unlike margin, would keep the section’s size intact. But with borders applied, it’s clear: the nested sections don’t span the full column, and the parent’s padding is removed outward. Why?”

I insisted: “I don’t understand — but I think you don’t understand either.” I re‑explained everything, again and again. Copilot kept replying with more code, more selectors, more “fixes.” At one point, it blamed my section section selector and told me to use section > section instead. But I wasn’t about to waste another night. When I saw its “Practical fixes (pick one)” list, I closed the window. And finally, I started to think for myself — something I had forgotten to do during this whole nightmare series.

And that’s when clarity struck.

With hindsight, my biggest mistake was obvious: I trusted Copilot. I built my reasoning on a house of cards, and of course, it collapsed. Somewhere in this series, I slipped into a bad habit — asking Copilot questions far beyond its true role. Instead of keeping it where it shines, refining my drafts, I leaned on it for CSS advice. That subtle shift was enough to derail me.

Each answer sounded authoritative, solid enough to build upon. But here’s the harsh truth: Copilot may know more CSS terminology than I do, yet that doesn’t make it a CSS expert. It only repeats patterns it has learned — with the same conviction, whether they are right or wrong. The deeper problem wasn’t just that Copilot couldn’t test code or see the browser — it was that it couldn’t even spot the obvious flaws staring back from its own suggestions.

Confidence. A fool’s substitute for intelligence.Dr. Robotnik

And that’s the point: Copilot isn’t thinking. It doesn’t reason, it doesn’t check, it doesn’t understand. It only echoes patterns with the same polished confidence, whether those patterns fit the situation or not. Suggesting selectors that stack indentation, or blaming a padding mismatch on decimal rounding instead of reduced width — these aren’t subtle mysteries, they’re fundamentals.

I was the one who mistook that confidence for competence. In truth, there’s nothing intelligent behind the name — just the illusion of it, carried by a single initial. I was the one who mistook those echoes for insight. I let myself be lulled by that tone of authority. By skipping my own verification, I wasn’t just careless — I was outsourcing my judgment. That’s how the house of cards grew taller, and how it inevitably toppled.

Now I see the shortcut for what it was — a trap. Instead of leaning on Copilot for answers, I should have followed the CogitActive principles: dig deep, study until there is nothing left to read, absorb the subject matter completely — that is the Cogit part. Only then comes the Active: test the code myself, wrestle with it, break it, fix it. Trial and error is the best teacher, and the only one that leaves lasting understanding.

Of course, time was the issue, and shortcuts were tempting. Normally, I resist that temptation. But in this series, I cut corners. I traded discipline for convenience, and convenience for speed. Time was the excuse, but clarity was the cost. Every skipped step, every untested assumption, was another card stacked higher, waiting for collapse.

The lesson is sharp: Copilot is an outstanding partner in writing, but not a substitute for my own verification. Editing is its lane. Testing and reasoning must remain mine. If I forget that, I’ll only be stacking cards again, waiting for the next collapse.

The truth is that I was lazy. As I admitted in the textbox above, I trusted Copilot instead of doing the work myself. Yes, I had played with DevTools back then. Remember the turning point — the moment I saw, as described in my earlier post, that with padding (unlike margin), the sections stacked like blocks on top of each other, not like Russian dolls. But I stopped too soon. I didn’t go beyond H3. I judged the book by its cover. Wrong.

From that moment on, I carried a false conviction through the entire series, reinforced by Copilot’s repetition: with margin, sections shrink because the empty space sits outside the box; with padding, the staircase looks similar, but the sections keep their width, no matter how deeply nested. box‑sizing: border‑box only muddied the waters further. I believed I had two distinct patterns — margin carving space outward, padding piling space inward, while the boxes themselves stayed constant.

How wrong. How blind.

I didn’t see it earlier because I never put my hands fully into the code. I trusted Copilot instead. I took its claims for facts — a truth that was a lie, a house of cards from the very beginning. And I never saw it. Even when I was ready to reject %, it would have been for the wrong reason. I was convinced that padding, as opposed to margin, preserved width, that no matter how many levels deep the sections went, they would always remain the same size. But they don’t.

Why? Because each section lives inside the content area of its parent. And every parent’s padding narrows that content area. The child inherits not just the nesting, but the reduced width. And this repeats at every level. Every level, except for H2 and H3. That exception is the key to the verdict — and it deserves its own chapter. Yes, you have read that correctly, a verdict. However, you’ll have to wait until next week for the full account.

The staircase to clarity is rarely straight. It tilts, it wobbles, it collapses — and then it teaches. For myself, I want to remember: don’t rush, don’t assume, don’t dismiss too quickly. The CogitActive way is not about shortcuts; it is about patience, precision, and the courage to wrestle with confusion until it finally yields insight.

Coming next: Verdict