Responsive grid & layout container
Purpose: Understand AEM's layout container, breakpoint behaviour and author-controlled layout.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Frontend engineers | Layout mechanics |
What it is
The layout container (wcm/foundation/components/responsivegrid) is AEM's authorable grid: authors place components in it and can resize/reflow them per breakpoint in Layout mode — no code per arrangement.
.aem-Grid (12 columns, breakpoints from template policy)
└── .aem-GridColumn .aem-GridColumn--default--8 .aem-GridColumn--phone--12
(plan card: 8 cols desktop, full width phone — authored, not coded)
Where the pieces live
| Piece | Location |
|---|---|
| Breakpoint definitions | Template structure (cq:responsive config) |
| Grid CSS generation | grid.less from product, compiled into your base clientlib |
| Author resize data | cq:responsive nodes under each component instance |
| Allowed components per container | Template policy |
Working with it
- Your components should be width-agnostic: fill the container, use internal responsive rules (container queries/percentages), never assume a column count.
- Component-internal layout (the benefits table's columns) is your CSS; page-level arrangement is the author's grid. Keep the boundary clean.
- Nested layout containers are allowed but each level adds authoring complexity — templates usually cap nesting via policy.
- If designers want pixel-exact non-grid layouts, that is a fixed template structure conversation, not a grid fight.