When the semantic <section> element met style concl’d (resumed)

From wild guessing…

For the sake of telling this story, I will measure in pixels. Not because they hold the crown — far from it, as you should already know — but because they give me a tangible scale, a ruler against which the other contenders can be judged. With px as the baseline, the abstractions of rem and % become easier to grasp: 1 rem equals 16 px, which, within my 525‑pixel column, translates to just over 3% ⁴. In this way, px becomes the lingua franca, the bridge that allows me to move forward even though I have not yet decided on the unit to adopt.

The challenge, then, is not mathematical but perceptual. What indentation feels right to the eye? Sixteen pixels — the quiet voice of 1 rem — may whisper hierarchy, subtle yet legible. Fifty‑two and a half pixels — the bold gesture of 10% — may shout it, carving a canyon between parent and child. Beyond that, indentation risks becoming theatrical, a gesture so grand it distracts from the text itself. The art lies in choosing a measure that guides the reader’s gaze without stealing the stage.

Web designers often struggle with how to size content and space elements consistently. Issues like choosing a max container width, balancing section padding vs. margins, setting text sizing, and spacing stacks of text and images can feel like a minefield.Kerri Cuthbert

“What about 40 px? That’s the default padding‑left for lists.”
“Which makes it 2.5 rem, doesn’t it? And, for the record, 7.6190476190476190476190476190476 % of my 525‑pixel column.”
“Do you really want to litter your stylesheets with decimals that stretch on forever?”
“Nope. There must be a better way…”

They were there, scattered like footprints: 0.5 em, 1 em, climbing steadily up to 3 em. em! Most were em indeed, with only a handful daring to be rem or px, and fewer still venturing into %. Some values even dipped into the negative, as if retreating rather than advancing. None of them spoke to my use case. As you may recall from a previous post, even the default 40 px padding‑left for lists had been annihilated to zero, erased without ceremony. And then, tucked away, I discovered a 65 px margin‑left for .comment‑body. Closer, perhaps, to what I sought — but still not the answer.

…to a practical approach

Don’t be afraid to experiment! There’s no one-size-fits-all approach to margins and padding. The best way to find what works for your website is to try different combinations and see what feels right.Pratiksha Ekbote

Do you recall my footnote #2? It spoke of a technique designed to keep line length within reach: no more than 80 characters, so that readers — especially those with visual or cognitive challenges — can follow the text without losing their place. Yet the story goes deeper. You may have come across the oft‑repeated claim: The ideal line length for readable text is 50–75 characters per line (CPL), with 66 CPL as the sweet spot. Within this span, readers are said to process information with ease, neither overwhelmed by long stretches nor interrupted by constant breaks. Too long, and the eye falters in its return to the next line. Too short, and the rhythm collapses into endless scrolling or paging. But it is worth remembering that this wisdom springs from traditional research in print, and from one influential source in particular:

Bringhurst, R. (1992). Horizontal Motion. The Elements of Typographic Style, pp 25-36. Point Roberts, WA: Hartley & Marks.

Digital design often borrows this wisdom wholesale, forgetting to adapt it to the screen. As the Wikipedia article on the subject matter cautions, Screen reading poses additional challenges, making the adoption of traditional line length research to the digital format problematic. Yet research specific to digital text has begun to fill this gap. One study explored how line length interacts with reading speed, comprehension, and scrolling behavior, and found that a medium line length — around 55 characters per line — produced the best balance: faster reading without sacrificing understanding. So, rather than relying on the 66 CPL inherited from print traditions, I will take the 55 CPL identified in this study as my guide:

Dyson, M. C., & Haselgrove, M. (2001). The influence of reading speed and line length on the effectiveness of reading from screen. International Journal of Human‑Computer Studies, 54(4), 585–612.

Indentation always comes at a cost: every step inward reduces the width available for your words. Reduce it too much, and your lines become too short — choppy, tiring to read, and visually unbalanced. I wanted a system that would keep even my deepest nested headings within the bounds of readability. Instead of choosing indentation values by eye, I think of them as part of my CPL budget. How much can I spend from my 525-px fixed amount of horizontal space without ever dropping below the ideal 55 CPL?

Designing indentation that respects CPL.

The first step was to measure the average character width in my theme. With a little help from AIs, I estimated it from the font‑family and font‑size defined in my stylesheet: about 7.5 px per character. Multiply that by the ideal 55 characters per line, and you arrive at a sweet spot of 412.5 px. Against my 525‑px column, that leaves 112.5 px of “space to spend” before falling below the target CPL. Divide this allowance by the maximum depth of indentation (H3 through H6, though in practice I rarely go beyond H4), and the result is a clean rhythm of 28.125 px per step. Round that figure to the nearest value on the 8‑point grid, and the cadence resolves neatly at 32  px — a number that feels both precise and harmonious.

I turn a fuzzy visual choice (“1 rem, 2 rem, or 3rem?”) into a typographic constraint problem with a numeric answer. No guesswork. No arbitrary numbers. Just a clean typographic system.

“32 px! That’s a lot — it eats too much horizontal space. Remember, most people skip indentation altogether because that space is precious.”
“I know. But smaller steps, like 16 px, don’t create enough visual separation. At 24 px, the structure begins to hold together, though it still feels a little tight. Rounding up to 32 px, by contrast, gives the hierarchy more breathing room.”
“Fair. But what about the other rules? Indentation should be at least the size of your body font to be noticeable, and no more than two or three times that. Or, keep the deepest indentation under 10 % of the column width.”
“For the first, I’m within the two‑to‑three‑times range. For the second, it only really works at the first level. Still, I’ve seen another guideline: nested sections shouldn’t reduce the text block by more than 5–10 % per level. That fits. Where did you pick up these rules, anyway?”
“Copilot. It says they’re good upper bounds for long‑form reading. No sources, but it does note that readability research warns against cutting line length too aggressively — deep indentation eats into the optimal 60–75 characters per line.”
“Exactly. QED.”

Media query

Media queries are a more definitive set of CSS codes based on the actual media screen width of the device.Saptak Sengupta

Media queries are the classic tool. Their principle is simple: detect the width of the viewport and adjust styles accordingly. On paper, they seem tailor‑made for my problem. I could imagine a neat progression — 16 px indentation for tablets, 12 px for larger phones, and finally, on the tiniest screens, surrendering indentation altogether in the name of readability.

Viewport

The visible area of a web page within the browser window — the “frame” through which the user sees your content.

But here’s where theory collides with reality. The moment I began exploring media queries — not even coding yet, just reading — I felt the ground shift. They aren’t just about distinguishing “phone versus desktop.” They reach into every corner of device behavior: resolution, orientation, aspect ratio, and even user preferences like reduced motion or data saving. Here’s how the MDN article on the subject opens:

Media queries allow you to apply CSS styles depending on a device’s media type (such as print vs. screen) or other features or characteristics such as screen resolution or orientation, aspect ratio, browser viewport width or height, user preferences such as preferring reduced motion, data usage, or transparency.

I pressed on — tutorials, articles, videos (Kevin Powell’s channel (external link) , in particular), and more — and the pattern became clear. Media queries look deceptively simple, but to wield them well, I would need fluency in syntax, a strategy for multiple breakpoints, and foresight for the endless zoo of devices. That’s when the panic returned: what is the viewport of a phone, exactly? How many breakpoints are enough? Which ones matter? My search led me to an article bluntly titled The ideal viewport doesn’t exist (external link) — and suddenly the neat plan of breakpoints felt like chasing a mirage.

What should have been a straightforward adjustment revealed itself as a labyrinth. And even if I mastered the maze, media queries remain blunt instruments: they respond only to screen size, not to the actual container where the text sits. They solve the broad strokes but miss the finer details.

So while media queries carry the weight of tradition and promise, their complexity — and their lack of precision — push me to look elsewhere.

Container queries

Container queries are the new kid on the block. Their principle is elegant: instead of listening to the entire viewport, they respond to the size of the container itself. In theory, this is exactly what I need. My indentation doesn’t care whether the user is on a phone or a desktop — it cares about the width of the column where the text lives. With container queries, I could finally adjust indentation in direct proportion to the actual reading space.

Unfortunately, they don’t magically eliminate the need to define thresholds; they simply shift the reference point. Instead of saying “when the viewport is more than 800 px wide, do X”, you say “when this container is 340 px wide, do X.” That means I still have to decide where the cuts happen. They don’t free me from the tyranny of breakpoints—the same deal‑breaker as media queries.

Moreover, container queries are still relatively new, and browser support, while improving, isn’t universal. They also demand a different mindset: you have to mark up your HTML with container elements, define them carefully, and think in terms of nested contexts. That’s a lot of extra scaffolding compared to the simplicity of a viewport‑based query.

And for someone like me, still learning the ropes, the documentation can feel intimidating. It’s not just “write a query and move on.” It’s “restructure your layout so containers exist, then query them.” Powerful, yes — but also heavier than I expected.

clamp()

The clamp() function is a responsive design superstar. It evaluates its three arguments dynamically: if the preferred value dips below the minimum, it uses the minimum; if it exceeds the maximum, it uses the maximum; otherwise, it goes with the preferred.Gabriel Shoyombo

Clamp is a CSS function that promises fluid scaling. Its principle is straightforward: you give it three values — a minimum, a preferred scaling value, and a maximum — and the browser slides smoothly between them as the available width changes. In theory, this is liberating. No breakpoints to juggle, no blunt “if/else” rules — just a graceful curve that responds as the screen or container changes. The syntax looks like this:

clamp(8px, 1.88vw, 32px);

The preferred value — here, 1.88vw to approximate 24 px on a 1280 px viewport — is chosen if it falls within the bounds. Otherwise, the function snaps to the minimum or maximum, creating a flexible layout without media queries. Imagine saying: “Indentation should never drop below 8 px, it should ideally scale with 1.88vw, but it must never exceed 32 px.” The indentation grows and shrinks gracefully with the viewport, always staying between 8 px and 32 px. It feels effortless, almost like a magic trick.

vw       Relative to 1% of the width of the viewport

These bounds — especially the maximum — are critical when using vw. Without them, indentation could balloon uncontrollably on ultra‑wide screens. With clamp, the browser takes care of the rest:

Phones (≈375 px) → 1.88vw ≈ 7 px, but clamp enforces the minimum, so indentation stays at 8 px.

Tablets (≈768 px) → 1.88vw ≈ 14 px, comfortably within bounds, so indentation scales naturally.

Large desktop (≈1920 px) → 1.88vw ≈ 36 px, but clamp caps it at 32 px, preventing runaway spacing.

Clamp would give me a neat progression: from 32 px on wide screens down through 24 px, 16 px, even 8 px on smaller ones. That part works beautifully — vw handles the scaling, and the maximum keeps indentation from ballooning on oversized displays. Yet my final option, “surrendering indentation altogether on the tiniest screens in the name of readability,” is out of reach. For clamp() to deliver a true zero, the minimum would have to be set at 0 px. But because the preferred value is tied to vw, it will never naturally shrink that far — even the narrowest realistic viewport still produces a positive value.

Below 8 px, indentation stops making sense anyway: what I need is not more fluidity, but a hard drop from 8 straight to 0. That clamp() cannot do. So clamp offers a graceful curve between extremes, but it doesn’t solve my problem. It’s clever, even seductive, but in the end, not good enough.

Attempt #1

On large screens, the target was clear: 5.36 cqi, which translates to 28.125 px on my 525 px column. Actually, I could even use 6 cqi (i.e., the upper 32 px rounding value). But left alone, that 6 cqi refused to shrink enough on smaller viewports: on a 340 px column (a phone), it still held at 20.4 px. Worse, it could never collapse to zero, nor perform the graceful drop from 8 px to 0 px that I had argued for earlier. So the challenge sharpened: how to craft a single CSS expression — no media queries — that behaves like 6 cqi on wide screens, 3 cqi across a chosen viewport range, and then bottoms out, reaching a defined floor, on the narrowest displays.

section.nested {
  margin-inline-start: max( min(6cqi, calc(3cqi + (100vw - 768px) * 200)), max(0cqi, min(3cqi, calc((100vw - 480px) * 200))) );
}

On paper, the math checks out. It works. The logic is sound. The expression does exactly what I asked of it. And yet, here is the truth: it isn’t elegant. It isn’t clean. It is unconventional, even precarious. It’s just a convoluted way of doing what a media query already does. Yes, I had to choose two breakpoints—480px and 768px—to anchor the behavior. In the end, it might feel like a clever trick, but it’s not a sustainable solution.

section.nested { 
  margin-inline-start: 0cqi; 
}

@media screen and (min-width: 480px) {
  section.nested { margin-inline-start: 3cqi; } 
} 

@media screen and (min-width: 768px) {
  Section.nested { margin-inline-start: 6cqi; } 
}

Attempt #2

Once I saw the flaw — my dependence on breakpoints, the very thing that had made me reject media queries in the first place — I picked up my pencil again and returned to the equation. The Heaviside step function lingered in my notes, a tool that CSS could never wield. Or could it? I stared at the page, waiting for something to surface. Nothing came. Until…

Until I fell asleep right there at my desk. When I woke, the equation was still waiting. But the night had done its work. Out of sleep came the spark — the idea that had eluded me while awake. If calc(3cqi - 8px) dropped below zero, then the indent should collapse to 0cqi. Below 8 pixels, indentation is indeed pointless. The vision was the equation that captured that truth.

The path to the final solution, however, was still hidden. I pressed on, scratching notes, testing variations (on the paper), chasing each thread of logic as far as it would go. Hours passed before the outline of an answer began to show.

section.nested {
  margin-inline-start: calc(3cqi * clamp(0, calc(3cqi - 8px) / 1px), 1) + 3cqi * clamp(0, calc((3cqi – 15.725px) / 1px), 1));
}

This is pure CSS, no media queries, no JavaScript. It uses container units so the thresholds are compared to the container’s actual inline size. Genius! Pure genius. What I had built was, in effect, a piecewise function written directly in CSS. The logic was simple but powerful: two thresholds, two steps. Here’s how it works:

• Each clamp() acts like a switch.
• When the value inside drops below the threshold, the result is 0.
• When it reaches or exceeds the threshold, the result flips to 1.
• Multiply that by 3cqi, and you get either nothing (0) or a full 3 cqi indent.
• Add the two together, and the margin grows in stages — first at 8 px, then again at 15.725 px.

In other words, the code mimics the behavior of a mathematical piecewise function: below the cutoff, no indent; above it, the indent appears in discrete steps. Of course, this required defining not just one threshold but two. And that was the moment I realized…

The 8‑pixel cutoff had come naturally from my earlier drafting: 32px was far too wide for mobile, 16px still felt cramped, but 8px struck a balance — small enough to protect readability, yet visible enough to signal hierarchy. In theory!

The second threshold, though, was trickier. To find it, I turned to DevTools and began experimenting with the responsive options. Using 3 cqi as my base, I watched how the margin behaved as the column approached its maximum width of 525 px. Strangely, before settling at that cap, the indent spiked higher, only to drop back again.

To play it safe, I leaned on the preset devices. Phones, tablets — I checked them all. No clear pattern emerged. So I took the largest value I saw: the iPad Pro, with an indent of 15.725 px. And no, I’m not a Mac fan boy; quite the opposite. But that is indeed the second time in this post I found myself citing an Apple product.

The second thing that stood out was the process itself — the way I hunted for values, tested devices, and tried to anchor the behavior. What I was really doing, without realizing it, was stumbling into the logic of container queries. DevTools was showing me not only the indent, but also the size of the content column itself (i.e., indent width + content width). In other words, I already had the container’s dimensions — my H2 section. That’s indeed a container query in disguise. Which means the code above could just as well have been written like this:

section.nested {
  margin-inline-start: calc(3cqi * clamp(0, (100cqi - 266px) / 1px, 1) + 3cqi * clamp(0, (100cqi – 524.3px) / 1px, 1));
}

Or, if coded properly:

@container (min-width: 266px) {
  section.nested { margin-inline-start: 3cqi; }
} 

@container (min-width: 524.3px) {
  section.nested { margin-inline-start: 6cqi; } 
}

Sometimes the most powerful breakthrough is realizing that the tool you tried so hard to avoid may, in fact, be the simplest answer.