Layout
Monster layout is built around stable spacing tokens, container-aware composition and predictable layers. The goal is not “fancy CSS”, but interfaces that stay readable when a split panel shrinks, when dark mode switches, and when components start nesting.
Core Principles
These principle blocks use a lighter documentation pattern on purpose. They are not meant to model application surfaces. Use Monster card and surface styles for actual UI containers, and use this flatter rhythm for rules that should scan quickly.
Container first
Prefer @container rules over viewport-only logic for component-level responsiveness. A component should react to the space it actually gets, not to the whole screen width.
Use tokens, not ad-hoc spacing
Base gaps, padding and offsets on the --monster-space-* scale. That keeps pages visually aligned and makes density changes possible without rewriting every example.
Compose simple structures
Most layouts can be expressed as stack, cluster or split. Once those three patterns are stable, cards, toolbars, forms and side panels become much easier to reason about.
Let overlays own layering
Do not invent local z-index: 9999 values in examples. Use the Monster layer tokens and the dedicated overlay components so dropdowns, poppers and dialogs share one stacking model.
Preferred Composition Patterns
Stack
Use vertical flow for forms, settings pages and article-like content.
Cluster
Use clustered items for badges, filters or short action groups that may wrap.
Split
Use split layouts when content and supporting controls need clear priority. The secondary area should collapse underneath when the container gets tight.
Card groups
Cards are surfaces, not a full layout strategy. Use them inside stack or grid structures instead of relying on cards alone to define page rhythm.
Responsive Behavior
For page-level shells, viewport breakpoints still matter. For embedded demos, component docs and split panels, container queries are the safer default. That is why current showroom examples switch from two columns to one column based on available container width.
| Use case | Prefer | Reason |
|---|---|---|
| Whole page shell | @media | Viewport-level navigation and global framing. |
| Embedded component demo | @container | Works correctly inside split panels and documentation tabs. |
| Form rows and helper panels | @container | Avoids crushed side columns when the parent panel narrows. |
| Artwork and broad landing sections | @media plus tokens | Best for top-level marketing-style composition. |
Spacing Scale
Monster spacing is intentionally small and consistent. Use the token values directly in CSS or their utility-class equivalents when the markup stays readable.
--monster-space-12px for tiny separators--monster-space-24px for dense inline gaps--monster-space-36px for compact controls--monster-space-410px for default internal breathing room--monster-space-516px for section gaps and card padding--monster-space-626px for larger group separation--monster-space-742px for strong section breaks| Utility classes | Purpose |
|---|---|
monster-margin-0..7 | Uniform outer spacing. |
monster-padding-0..7 | Uniform inner spacing. |
monster-margin-top-0..7 etc. | Directional spacing for precise adjustments. |
monster-padding-start-0..7 etc. | Logical padding that respects writing direction. |
Skeleton and Loading States
Use skeletons for content that will appear in place shortly. Use the global boot loader for the application shell itself. Those are different responsibilities and should stay separate.
Skeleton rows
Layering and Z-Index
Layer tokens define a shared stack order for dropdowns, sticky elements, modals and tooltips. If a demo needs an overlay, use the Monster layer system instead of arbitrary local stacking numbers.
| Token | Typical use |
|---|---|
--monster-z-index-default | Normal document flow and base components. |
--monster-z-index-dropdown | Selects, menus and lightweight floating panels. |
--monster-z-index-sticky | Sticky headers and controls that must stay above flowing content. |
--monster-z-index-modal | Dialogs and strong focus-taking interfaces. |
--monster-z-index-popover | Poppers and contextual overlays. |
--monster-z-index-tooltip | Small transient explanations above everything else. |
Display and Visibility Utilities
Utility display classes are useful for simple state changes, but they should not replace component state models. Use them for layout plumbing, not as a substitute for proper interaction logic.
| Class | Effect |
|---|---|
.block, .inline, .flex, .grid | Fast display switching for wrappers and demo shells. |
.hidden, .none, .hide | Completely remove an element from layout flow. |
.visible, .invisible | Keep layout participation while toggling visibility. |
Do and Don’t
Do
Combine Monster spacing tokens, logical padding and container queries so examples stay stable inside narrow documentation panels.
Don’t
Freeze demo layouts with fixed widths, random pixel gaps or ad-hoc breakpoints that only work on the full page.