FeaturesHow it worksPricingDocsBlogFAQ
Try for free

Blog

Headline budgets and section rhythm, explained

Two rules that decide whether a landing page reads as designed: sizing copy to the block it lives in, and giving the page a spacing and layout rhythm.

August 20, 2026 · Initium Team · 6 min read

A page can use good blocks and still look assembled rather than designed. The blocks are fine in isolation; the problem shows up in the seams, where a headline runs to four lines in a slot built for two, and where every section repeats the same centered layout at the same vertical spacing until the page reads as one long column of nothing in particular.

Two rules fix most of it. Size copy to its block, and give the page a rhythm. Both are mechanical enough to hand to an agent, which is the point.

What is a headline budget?

A headline budget is a limit on how much copy a heading slot can hold, expressed in visual lines rather than characters. The rule Initium encodes is two: every heading fits on at most two visual lines in the block it lives in, at every breakpoint you support.

The reason it is stated in lines and not words is that words are the wrong unit. A hero heading at text-6xl inside a max-w-2xl container holds far fewer words than an h3 inside a feature card, and both are governed by the same design intent: the heading should be readable as one gesture, not scanned as a paragraph. Line count is what the visitor actually perceives.

The rule also runs in a specific direction. Size the copy to the budget, not the block to the copy. When a headline needs a third line, the fix is a shorter headline, not a wider container or a smaller type step. Widening the container is how a page loses its type scale one section at a time.

How long should body copy be?

Headlines get a line budget. Body copy gets a measure, and here there is research to lean on rather than taste.

WCAG success criterion 1.4.8 (Level AAA) requires that text width be "no more than 80 characters or glyphs (40 if CJK)" for blocks of text, alongside minimum line spacing and a prohibition on justified text. Baymard's readability research narrows it further: research lead Edward Scott puts the optimal band at 50 to 75 characters per line, and recommends setting a max-width in font-relative units, around 70ch, so the measure holds as type scales.

In practice this is a container decision, not a per-paragraph one. Initium's wrapper class sets max-w-2xl on small screens and lg:max-w-6xl above, so full-width prose stays inside a sane measure and multi-column sections split the wider container into columns that land in the same band. If you write a custom section, check the measure of any paragraph that spans the full container before you ship it.

What does the browser do about wrapping?

Some of the budget is enforceable in CSS. text-wrap: balance distributes characters evenly across lines, which stops the classic heading that breaks as five words then one. Because balancing is expensive, browsers cap it: Chromium applies it to blocks of six lines or fewer, Firefox to ten. That cap is fine, since headings are the intended use.

text-wrap: pretty uses a slower algorithm tuned for body copy, mainly to avoid orphans. Tailwind exposes both as text-balance and text-pretty, and Initium's heading and paragraph utilities already apply text-pretty:

.heading-xl {
  @apply mb-5 font-heading text-4xl leading-none font-medium tracking-tight text-pretty text-foreground sm:mb-6 sm:text-6xl;
}

Wrapping utilities improve how a heading breaks. They do not shorten it. A five-line headline balanced across five lines is still over budget, so treat these as polish on top of the copy rule rather than a substitute for it.

What is section rhythm?

Rhythm is the pattern a page establishes as you scroll: how much air sits between sections, and how the layouts alternate.

The spacing half is a scale, not a set of judgment calls. Section padding comes from one utility with one set of steps, which is why wrapper carries py-16 sm:py-20 rather than each section choosing its own vertical padding. When a page mixes py-12, py-20, and py-32 across three consecutive sections, nothing is wrong with any of them individually, but the page loses the regular pulse that reads as intentional.

The layout half is alternation. Centered sections alternate with split ones, and split sections swap which side holds the media. A page that runs six consecutive centered sections has no rhythm; the visitor gets one shape repeated until they stop looking. This is the rule Initium states as zigzag: adjacent sections alternate so the page reads with movement.

Does the zigzag rule actually hold up?

Partly, and the caveat is worth knowing before you apply it everywhere.

Nielsen Norman Group ran eyetracking on the pattern in 2017. Kim Flaherty's study compared an aligned layout, where every image sits on the same side, against a zigzag layout that alternates image and text placement row by row. When the images carried information, users studied them under both layouts. When the images were decorative, the zigzag layout made them harder to skip: participants had learned the images were not useful, but the alternating placement was less predictable, so they kept accidentally fixating on them and redirecting back to the text.

The recommendations that follow are specific. Align decorative imagery down one side of the page rather than alternating it, put high-information content on the left in opening rows, and do not add imagery for the sake of the layout. The study also notes that zigzag is acceptable on pages with only two or three rows of content, which is most marketing sections.

So the honest version of the rule is not "alternate everything." It is that alternation is a tool against monotony, and it costs scanning efficiency when the thing being alternated is decoration. Alternate layout types across the page, keep the alternation deliberate over a small number of rows, and if a section's image is filler, the better fix is a real image or no image.

How do you apply this to blocks you install?

The rules are easiest to hold when you choose sections in sequence rather than one at a time. A workable pass over a page:

  1. Write the headlines first, at the length the budget allows, before choosing which block holds them.
  2. Pick each section so its shape differs from the one above it, alternating centered and split layouts.
  3. Install the sections, then read the page at the breakpoints you support, watching for headings that gain a third line at any width.
  4. Cut or rewrite whatever went over budget instead of adjusting the block.

Installing looks the same as any registry item:

npx shadcn@latest add @initium/hero-section-1 @initium/feature-section-4 @initium/logo-section-2

Since the code lands in your repo, the check in step 3 is a real check on real markup rather than a preview.

How do you make an agent follow the rules?

This is where the rules earn their mechanical phrasing. "Make it look designed" gives an agent nothing to act on. "Every heading fits at most two visual lines in its block, adjacent sections alternate centered and split layouts, section padding comes from the shared wrapper" is a set of constraints an agent can check its own output against.

Initium ships those constraints as an agent skill, so they load with the task instead of living in your head. The relevant file states the layout rules directly:

- **Headline budget:** every heading fits on at most two visual lines in its
  block. Size copy to the budget, not the block to the copy.
- **Zigzag rhythm:** adjacent sections alternate ...

The same text also serves as a review checklist for pages you wrote yourself. Both rules are verifiable by looking, which is what makes them useful in a workflow where an agent writes most of the markup and you approve it.

If you want the surrounding structure, how to structure a SaaS landing page covers section order, and anatomy of a hero section goes slot by slot through the block where headline budgets bite hardest. The style presets docs cover the spacing and type scales the rhythm rules assume.

Build a site that looks designed

Initium gives your coding agent the blocks, style presets, and skills behind everything on this blog.

Try for free

More from the blog

shadcnlanding-pages

Why AI-built marketing sites look generated (and how to fix it)

Coding agents ship layouts fast, but the result reads as template soup. Here is what actually makes a marketing site look designed — and how Initium encodes it.

1 min read

landing-pagesshadcn

Anatomy of a hero section that converts

What each slot in a hero section does, how much copy it can hold, and the implementation details that decide whether it loads and reads correctly.

7 min read

shadcnai-workflow

shadcn registries explained: installing blocks you own

What a shadcn registry actually is, what happens when you run npx shadcn add, how namespaces and private registries work, and why agents like them.

6 min read

On this page

  • What is a headline budget?
  • How long should body copy be?
  • What does the browser do about wrapping?
  • What is section rhythm?
  • Does the zigzag rule actually hold up?
  • How do you apply this to blocks you install?
  • How do you make an agent follow the rules?

Build a site that looks designed

Initium gives your coding agent the blocks, style presets, and skills behind everything on this blog.

Try for free

Plan it once. Build it right.

Stop handing AI a blank prompt. Give it your style, strategy and blocks, and let it build a site that looks designed, not generated.

Get lifetime access

Copyright © 2026 Matt Wierzbicki

Product

  • Features
  • Pricing
  • Style editor
  • Blocks browser

Resources

  • Docs
  • Blog
  • Changelog
  • FAQ

Legal

  • Privacy Policy
  • Terms of Service
  • License Agreement