What this prompt does
This prompt builds a complex CSS Grid layout step by step for a specific [page_type] that must arrange concrete [content_elements]. Instead of dumping a single grid declaration, it starts from named grid template areas, defines columns with your chosen [column_strategy], applies a [layout_pattern], then layers in responsive restructuring, dynamic card flow, alignment handling, animation, and fallbacks. Working from semantic area names first makes the layout readable and easy to rearrange per breakpoint.
The variables shape the geometry and behavior. [primary_span] decides how much visual weight the lead content carries, while [breakpoints], [mobile_width], and [tablet_layout] define how the grid collapses from a full complex desktop arrangement down to a stack with sensible order changes. [min_card_width] and [grid_gap] drive the auto-fill/auto-fit card section so items reflow naturally without per-item media queries, and [alignment_strategy] handles varying heights for a masonry-like flow. [use_container_queries] and [animation_approach] add component-level responsiveness and motion when the grid restructures on resize, so the layout adapts to both viewport and component context.
When to use it
- Building editorial or magazine-style homepages with a hero and asymmetric card arrangement.
- Laying out dashboards where panels need explicit grid placement and spanning.
- Creating responsive card grids that should reflow without media-query micromanagement.
- Planning a layout's breakpoint behavior before writing any CSS.
- Adding container-query responsiveness so components adapt to their own width, not just the viewport.
- Handling masonry-like visual flow with
[alignment_strategy]for uneven content heights.
Example output
You get production-oriented CSS plus explanation: a grid-template-areas map with meaningful names, grid-template-columns and grid-template-rows using your [column_strategy], spanning rules implementing the [layout_pattern] with the primary block at [primary_span], media queries (and optional @container queries) restructuring the grid at each of your [breakpoints], an auto-fit card section keyed to [min_card_width] and [grid_gap], transition handling via [animation_approach], fallbacks for older browsers, and ASCII diagrams of each breakpoint arrangement.
Pro tips
- Name your
[content_elements]precisely; vague element lists produce vague grid areas and weak hierarchy. - Choose
[column_strategy]deliberately: a 12-columnrepeatwith named lines gives you flexibility, while explicit tracks give you control. - Set
[min_card_width]to your real minimum readable card; too small and cards cram, too large and you get awkward gaps. - Decide
[use_container_queries]based on whether components appear at varying widths; for true reusable cards it usually pays off. - Keep
[grid_gap]consistent across sections so the page reads as one system, not stitched-together regions. - Treat the
[animation_approach]step as optional polish; verify the View Transitions path has a FLIP fallback before relying on it. - Lean on the generated ASCII diagrams to sanity-check each breakpoint arrangement before you commit the CSS to a real
[page_type]in production.
