Nestable Elements: Structure Before Style

Nestable elements are how Bricks layouts stay semantic without fighting the builder. Section wraps Blocks; Blocks wrap content; depth stays intentional. When everything is a free-floating Div, CSS selectors grow fragile and the DOM becomes a scrapbook of wrappers added just in case.

This article covers recommended nesting depth, class strategy, and how to keep structure predictable when multiple builders touch the same templates. Structure is part of the design system — treat it with the same seriousness you give color tokens.

Recommended nesting depth

Aim for a shallow tree that still expresses layout regions. A practical default:

Section
  └─ Container / Block
       ├─ Heading
       ├─ Text
       └─ Block (card)
            ├─ Icon
            ├─ Heading
            └─ Text

If you need a third nested Block to position a badge over an image, fine. If you need a sixth because each engineer added a wrapper instead of fixing alignment, flatten. Depth should buy clarity, not postpone decisions.

Sections versus blocks

Sections own vertical rhythm and full-bleed backgrounds. Blocks own internal layout: grids, stacks, and card chrome. Put background colors and section padding on the section (or a dedicated class on it). Put gap and alignment on the inner block. Mixing those responsibilities is how you get double padding mysteries.

On marketing pages, sections usually map to scroll destinations and content outlines. If your table of contents or sticky nav targets a section, keep that section’s identity stable instead of wrapping it in anonymous containers.

CSS targeting tip

Style via BEM classes on the elements you own. Avoid deep div div div selectors — Bricks may insert wrappers and your CSS will miss.

.service-card__title {
  font-family: var(--font-display);
  letter-spacing: -0.03em;
}
.service-card__body {
  color: var(--text-muted);
  line-height: 1.7;
}

Class names should match your design system and CSS chunks. Renaming classes in Bricks without renaming CSS is a silent visual regression waiting for the next deploy. Prefer adding a class over inventing a new nestable solely to attach a style.

Grids without wrapper soup

Prefer one grid container with children as direct grid items. Nesting a grid inside a flex inside a grid to center a single card is usually a sign the parent constraints are wrong. Fix the parent max-width and alignment before adding another nestable.

For responsive behavior, define grid template changes at your system breakpoints (640 / 1024 / 1280) rather than inventing new ones per section. Inconsistent breakpoints are why a card grid looks fine on the homepage and cramped on a service page.

Components and nestables together

Components encapsulate a nestable subtree. Keep the subtree readable in the structure panel. Lock only what must stay locked. Editors who cannot see how a card is built will duplicate pages instead of editing instances.

When a component grows too deep, split it. A pricing table component that contains an entire FAQ is two components wearing a trench coat.

Accessibility structure

Nesting should reinforce semantics: one H1 per page, heading levels that do not skip wildly, lists that are real lists, buttons that are buttons. A Block is not a reason to skip from H2 to H5 because the panel defaulted oddly.

Landmark regions matter on complex pages. Header, main, and footer should remain clear even when Bricks templates compose multiple sections. Skip links and focus order depend on that honesty.

Refactor signals

Flatten when you see wrappers whose only job is margin, especially if a spacing token on the parent would suffice. Flatten when class selectors need :nth-child chains to find content. Flatten when two builders disagree about which wrapper owns the background.

When in doubt, flatten. Extra nestable wrappers for future flexibility usually become future confusion.

Before a major visual polish pass, spend thirty minutes cleaning structure. Many CSS fights dissolve when the tree stops lying about what owns layout.

Structure before style. If the tree is honest, tokens and components have a place to live. If the tree is improvisational, every visual fix becomes a special case. Bricks nestables reward teams that treat DOM shape as part of the design system — not as leftover scaffolding.

Hand-off checklist for nestables

Before you pass a template to content editors, confirm the structure panel reads like an outline. Every major region should have a meaningful class. Decorative wrappers should be rare and named. If a new teammate cannot find the CTA block in ten seconds, the tree is too clever.

Also confirm responsive previews at your three system breakpoints after any nesting change. Flattening a wrapper can fix desktop CSS and break a mobile stack if gap ownership moved unexpectedly.