Posted on by CogitActive

The tangled tale of a CSS length unit

Introduction

Let me be upfront: this post will be different. Not just in tone, but in structure—if there’s any structure at all. Because what follows is not a tutorial, nor a conclusion, nor even a well-argued investigation. It’s a tale. A tangled one. Of confusion, indecision, and the maddening 1 search for something deceptively simple: the correct CSS length unit.

As readers of this blog—especially those who’ve followed my epic on the <section> element—already know, the post that was supposed to wrap up the series with a clean implementation of indentation for nested sections was abruptly interrupted. The culprit? A seemingly innocent question: padding-left or margin-left. What followed was a courtroom drama and a subsequent appeal. Yet, despite my best efforts, the verdict remains elusive: the jury is still deliberating.

Now, as explained in a previous post, even if I had managed to reach a verdict, I wouldn’t be able to resume my interrupted indentation post right away. Why? Because the choice of length unit is proving more complicated than anticipated. So rather than resume the post only to interrupt it again, I’ve decided to give this topic the full attention it demands. Today’s post will attempt—yes, attempt—to retrace the chaotic course of my search for a solution. A labyrinth of elusive standards, contradictions, shifting AI logic 2, and unanswered questions. A journey in which I’ve lost not only my path, but also my patience, my sleep, and—on more than one occasion—my sanity.

It was supposed to be simple

When I began drafting what was supposed to be the concluding post of this series, I genuinely believed it would be just that: an end. A final chapter. Closure. This series had already suffered too many unwanted “To be continued…” interruptions, and I was determined to move on. After all, I had a bonus project lined up—one that was meant to unfold over the summer—and I was still locked in battle with my nemesis: the powerful, but cursed <section> element.

The plan was simple. The structure of the post was already mapped out, and the task ahead seemed like a mere formality: describe how I would implement indentation for my nested sections. Nothing fancy. Just a clean wrap-up to a months-long investigation. Admittedly, I was exhausted. This series had stretched far beyond what I’d anticipated, and I was eager to turn the page. And the input I had at the time? Crystal clear. Both Copilot and Gemini, in their pre-trial confidence, offered the same solution with unwavering certainty:

.section-h2 {
  padding-left: 1rem;
}

So, the post was structured and ready to roll. It would begin with a bold H2: Implementing indentation, followed by a series of H3s that would walk the reader through the final considerations:

  • A third caveat
  • Targeting the hierarchy
  • Which CSS property? ← the infamous heading where everything fell apart
  • Which unit?
  • How much is enough?
  • What about smartphones?

And finally, a closing H2: Your turn—a call for feedback, a chance to pass the torch.

That was the blueprint. Neat. Logical. Optimistic. And then came the interruption.

The collapse of certainty

When I was drafting the appeal post—the second act in the padding-left vs. margin-left courtroom drama—I genuinely believed it would mark the rise of margin-left. Oh, naïve again 3. So, I moved on. Or tried to. I began working on the next post—the one meant to resume the interrupted conclusion. The plan was to resume exactly where the interrupted post had left off, so I had a beautiful H3 ready: Which CSS property? (solved).

Turns out, the case wasn’t solved at all. What I had framed as the triumphant rise of margin-left quietly unraveled into its fall. The arguments I had carefully assembled? Dismissed. My rhetorical scaffolding? Shaken. And the jury? Silent. Not a single comment. As of today, I still don’t know which property I should use. padding-left or margin-left—the verdict remains elusive.

So I skipped that part and moved on to the next heading: Which unit?. I was confident—or perhaps just blissfully ignorant—that this time, the task would be simple. All I had to do was explain CSS length units. Nothing controversial. Just a tidy breakdown: two main categories—absolute and relative. You don’t need a PhD in CSS to rule out the absolute units—fixed values like px don’t scale well across devices or accessibility settings. Responsiveness demands flexibility, and that’s where the relative units come in. Among those, the ones relevant to my use case were the two aforementioned contenders: em and rem.

For padding or margin, you’ll typically use rem or em depending on your specific requirements.Esther Christopher

“But which one?”

Given the constant flip-flopping in the AI suggestions I’d received, the choice didn’t seem so simple. One day it was em, the next it was rem, and then back again. I quickly realized this wouldn’t be an easy call—or more precisely, not a clear-cut one. And yet, when I finally dove into the research, it all seemed surprisingly straightforward. I came to a decision quickly. A solid one. A choice grounded in how the units actually work. A choice I could trust. A choice that felt… final. No “to be continued” ahead. So I started drafting.

Ironically, Copilot—who was supposed to stick to its editor role that day—suddenly improvised like an impulsive child and began drafting a post (unprompted!). I was just prompting that I’d need help drafting a post on CSS length units, explaining my use case, and was about to paste in my raw draft and ask for help polishing the English—when my stubby fingers hit Return a little too soon… Surprisingly, the conclusion of its draft confidently declared that I had chosen a unit as the best fit for my use case. The twist? I had not shared my choice. And worse, its confident conclusion was the exact opposite.

That little spark would soon ignite the mess I’m still trying to untangle.

Not so binary after all

When I began drafting that other post (the one I thought would wrap things up neatly, I had a clear structure in mind for my H3 “Which unit?”—and no reason to expect surprises. The plan was simple: introduce the two families of CSS length units, absolute and relative. Mention px as the lone survivor of the former, then move on to the latter, where em and rem reside. From there, I’d walk through the relative units one by one, dismissing each with a brief rationale, until I arrived at the final contenders— rem and em (or em and rem, depending on which one I chose—but I’m not telling). I had most of the draft ready. But then, as you know, my stubby finger hit Return. And everything changed. Still, let’s pretend I didn’t. Let’s imagine Copilot had done what I was about to ask: polish the draft, not derail it.

Absolute vs. relative units

In CSS, indentation is expressed as a length 4—and lengths come in two broad families: absolute and relative. Absolute units, like px, mm, cm, in, pt, and pc, have fixed values. They remain constant regardless of context and are typically used when precision is paramount. Relative units, on the other hand, scale dynamically. Their values depend on surrounding elements—whether it’s the font size of the current element, its parent, or the root.

Each unit has its own strengths, and knowing when to use which is part of the craft.

Among the absolute units, most—millimeters, centimeters, inches, points, and picas—are remnants of the print era. They still serve a purpose in page layout and physical media, but they’re rarely recommended for screen design, where device sizes and resolutions vary wildly. The lone exception is the pixel (px), which remains a staple of web design. It’s widely used for defining fixed-size elements like borders, offering a predictable, consistent measure. But that predictability is also its flaw: px doesn’t adapt well to different devices or user settings, which made it unsuitable for my indentation needs.

Unlike their fixed counterparts, relative units respond to context. They specify lengths in relation to other properties, making them far more suitable for responsive design. There are quite a few: %, em, rem, ex, ch… and more. For this discussion, I’ll focus only on those relevant to indentation.

The unit I meant to reject

I had my two contenders lined up—ready to close the section with my top pick 5. But to make the progression feel more natural, I decided to include a few other relative units first. Just for completeness (this blog aims to be informative, after all). Among the many options, I picked % to start with. Why? No particular reason. It was not meant to be a serious candidate. I began drafting its section with the intention of dismissing it quickly and moving on.

%     Relative to the parent element

The percentage unit (%) expresses a length relative to the containing block—usually the width of the parent element. In practice, that “parent” is the box that defines the child’s layout context. For block-level elements, it’s typically the nearest ancestor with a defined width; if none is set, the browser defaults to the width of the parent’s content area.

In my case, a <section> usually sits inside another <section> or directly within the main content column of the theme. That column has a maximum width of about 525 px, so an indent of 10 % resolves to roughly 52 px on a desktop screen. When the screen narrows, the column contracts—and the indent contracts with it. On my laptop, simulating a phone-sized display in developer tools, the same 10 % dropped to about 20 px. In other words, the percentage unit mirrors the container’s width with surprising fidelity: wide container, wide indent; narrow container, narrow indent.

I was midway through drafting the above section—still convinced I was laying the groundwork for a quick dismissal—when something shifted (thanks, incidentally, to the unprompted Copilot draft that nudged me into playing with the developer tools in the first place). The realization in the aside above (i.e., my mea culpa) was the turning point: the container itself responds gracefully; em or rem were not. So, % wouldn’t just behave well; it would adapt. Reliably. Predictably. And suddenly, I realized this unit wasn’t just acceptable. It was good. Better than good, actually. Especially for small screens. I had assumed vw would be my go-to for smartphones—a viewport-based unit seemed like the obvious choice. But here was %, quietly mirroring the container’s width with perfect proportionality. That’s not just responsive—it’s elegantly responsive.

And I couldn’t help but wonder: why had no one mentioned this? I had combed through hundreds of examples—okay, not that many, but enough to notice a pattern. When it came to indentation via padding-left or margin-left, the recommendations were always the same: em, rem, and occasionally px. But never %. Not once. Why was the most context-aware unit hiding in plain sight?

Tug-of-war in the mad

% looked promising: elegant, responsive, and surprisingly effective. It felt like the answer I’d been chasing. But you know how I work (yes, the CogitActive principle), so I couldn’t stop there. I dove deeper. And that’s when the second wave hit — a tug-of-war not just between contenders, but between contexts, assumptions, and the very meaning of indentation itself. What follows isn’t a resolution. It’s how the illusion of resolution ends up face-down in the mud.

When % hit THE wall

As explained earlier, the percentage unit (%) expresses length relative to the containing block — typically the width of the parent element. This makes it inherently responsive: as the container grows or shrinks, so does the value. No need for media queries, no need for complex calculations. Just proportional elegance. It’s one of the most intuitive tools in the CSS arsenal.

Let’s unpack how % actually behaves. For block-level elements, the percentage is usually calculated against the width of the nearest ancestor with a defined width. If no such width is set, the browser defaults to the content area of the parent. This means that the effectiveness of % hinges entirely on the layout context — and more specifically, on whether the parent’s width is stable and predictable.

In my case, the layout is built around nested <section> elements. These sections typically reside within a main content column — a container with a maximum width of about 525 px. So far, so good. But here’s the catch: that reference point doesn’t always hold. Whether the nested sections retain the full width of the container depends entirely on how I apply the indentation — specifically, whether I use padding-left or margin-left. If you remember my Russian dolls experiment, you’ll know that padding-left behaves like a gentle nudge inward. It adds space inside the box, shifting the content without altering the box’s overall width. The container remains intact, and the percentage unit continues to reference the same stable width — even as the nesting deepens. margin-left, however, plays by different rules. It pushes the entire box outward — to the right — but the container doesn’t budge. There’s a wall there. A hard limit. And with each level of nesting, the section gets shoved further into that wall. The result? The available width shrinks. The deeper the nesting, the narrower the section becomes. The elegant proportionality of % begins to falter. Not because the unit misbehaves—but because the context shifts beneath it.

The problem isn’t with % itself. It’s not that its behavior is inconsistent across CSS properties, or that it somehow miscalculates. % continues to reference the width of the parent regardless of how deeply nested the section is. The issue is that padding-left and margin-left don’t affect the parent’s width in the same way.

Choosing a CSS unit isn’t just about the unit. The property matters. The context matters. If I go with padding-left, % remains viable. If I choose margin-left, it doesn’t. And since I still don’t have a verdict on the property itself, I can’t commit to the unit either.

So % is on pause.

Back to em vs rem

em and rem are the two relative lengths you are likely to encounter most frequently when sizing anything from boxes to text.MDN

em     Relative to the font-size of the element

In CSS, the em unit is relative to the font size of the element it’s applied to. If that element doesn’t have an explicit font size, it inherits from its parent. This makes em highly contextual — and that’s both its strength and its weakness. On paper, em offers flexibility. It adapts to its environment, scaling naturally with the font size of the current element. If you increase the font size of a section, the indentation grows accordingly. That sounds like responsiveness, doesn’t it?

The difference is subtle but important. With em, indentation depth mirrors semantic depth: each nested <section> pushes further right, step by step. With rem, every section would be indented the same amount, regardless of how deep it sits in the hierarchy.Copilot

And to be fair, the rationale was solid. Indentation expressed in em compounds naturally with nesting: each level adds its own offset, proportional to its local context. It’s automatic. It’s elegant. A section with 2em nesting inside another 2em section ends up at 4em. But Copilot didn’t know my layout. It didn’t know I would be targeting my nested sections directly using descendant selectors: section section for level two (i.e., my <h3>), section section section for level three (i.e., <h4>), and so on. I wasn’t relying on inheritance or cascading styles. I was writing explicit rules for each level. So this compounding behavior wasn’t a feature — it was a nuisance. I didn’t want each level to double the indent. I wanted control. Precision. Predictability.

My concern was with my headings. Take a look at my theme’s CSS:

h1 {
	font-size: 24px;
	font-size: 1.5rem;
}

h2 {
	font-size: 20px;
	font-size: 1.25rem;
}

h3 {
	font-size: 18px;
	font-size: 1.125rem;
}

h4 {
	font-size: 16px;
	font-size: 1rem;
}

h5 {
	font-size: 13px;
	font-size: 0.8125rem;
}

h6 {
	font-size: 15px;
	font-size: 0.9375rem;
}

Each heading level has its own font size. I wasn’t sure whether those styles would affect the parent section, or if the section would inherit from them, or vice versa. A 2em indent might resolve to 36 px in one section and 32 px in another, simply because the font size context shifted. Who was the parent, anyway? The section? The heading? The container? This uncertainty made em feel unstable. If indentation was going to depend on font size — and font size was tangled up in a cascade of heading rules — then I couldn’t trust em to behave consistently.

To make it even easier to write style rules that depend only on the default font size, CSS has since 2013 a new unit: the rem. The rem (for “root em”) is the font size of the root element of the document. Unlike the em, which may be different for each element, the rem is constant throughout the document.W3C

rem     Relative to font-size of the root element

Unlike em, the rem unit is relative to the root element’s font size — typically the <html> element. This makes it stable. No matter where you apply it, 1rem always resolves to the same value (assuming the root font size doesn’t change). In my layout, that’s usually 16 px. So a 2rem indent is 32 px — everywhere. No surprises. No contextual drift. With rem, I could define a consistent indentation scale that held across all sections, regardless of nesting or inherited styles.

Because rem is tied to the root font size, any change at the top level — whether by me or by the user adjusting their browser settings — ripples through the layout. All rem-based margins and paddings scale accordingly. It’s not fluid in the % sense, but it’s adaptive. The design holds its proportions, even as the base size shifts. It’s subtle. It’s small. But it’s real.

It’s a good idea to use rem to set font sizes because it is designed to adapt to the user’s browser preferences. This helps with accessibility. It is also good for consistent scaling, as changing the HTML font size will affect the elements with rem units.Esther Christopher

“So… done deal, right? Go for rem and call it a day.”
“But what about %?”
“Why bother with %. It won’t even work if you go with margin-left. rem is clean. It’s consistent. It’s even a little responsive. What’s not to love?”
“Still… rem is tied to font size. It’s a font-based unit. It’s not spacing for spacing’s sake — it’s spacing derived from typography.”
“That’s not necessarily bad. In fact, it’s often good. It creates harmony between text and layout. Spacing scales proportionally with text, keeping things readable and visually balanced — especially when users adjust their browser’s default font size.”
“Maybe…”

So I’ll leave it here—for now. Still alone in the empty courtroom, I’m staring at the bench—better known as the comment section of The case isn’t closed: padding-left vs margin-left—waiting for the jury to return with a verdict. Until then, the indentation remains unresolved. The unit? Undecided. And the madness… very much ongoing.

1 If you read the last post, you already know — I’m spiraling into madness. But don’t worry, my brain is not completely fried yet. ^
2 I should have known better. After the debacle of the padding-left vs. margin-left drama, you’d think I’d learned my lesson. And yet, when the void of information hit again—when the specs grew silent and the forums offered nothing but conflicting opinions—I had nobody else to turn to. So, I asked Copilot. Not just for editorial help (in which it excels, I must admit), but for guidance. For clarity. For answers. What I got instead was a cascade of contradictions, shifting logic, and even more confusion. ^
3 In my appeal post, I truly believed margin-left was about to triumph. But then came the hiccups. Both Copilot and Gemini had confidently cited its use for indentation in tables of contents, comment threads, and lists. A strong argument in its favor, right? But when I double-checked for myself, I discovered that their claims didn’t hold up. Lists (ul, ol) rely on padding-left by default. Comment threads? Sometimes margin-left, sometimes not. The examples I had taken for granted turned out to be inconsistent. A strong argument—collapsed like a house of cards. ^
4 For a complete overview of all CSS length units (external link), see the excellent MDN reference. ^
5 Technically, I was closing with this: “What about the viewport units?” To which it replied, “Ah, yes, those. They deserve their own discussion—I’ll come back to them later.” I was saving that for the H3 What about smartphones?. So yes, em and rem were meant to be the final contenders… but not the final words. ^