Original illustrative specimen, generated from this entry’s specification. Not a photograph and not a third-party asset.
Definition
Arranges content as a tight mosaic of rounded tiles at varying spans, each holding exactly one idea, so a dense overview stays scannable.
Classification
Tagsbento · grid · modular
Aliasesbento grid, bento box, tile layout, modular grid
Specimen
OriginOriginal illustrative demonstration, rendered in HTML and CSS from this entry’s specification. Not a photograph and not a third-party asset.
Core principles
One idea per compartment.
A tile holds a single claim, metric, image, or feature; two ideas mean two tiles.
Size communicates importance.
Span is the mechanism for emphasis, not a container to be filled with more material.
The mosaic is full.
Holes inside the bounding rectangle read as a broken grid rather than a composed one.
Reference material
Agent prompt
Applying a Bento visual direction
You are being asked to apply a Bento visual direction to a web interface. This document gives you framing and recommendations for that direction. It does not tell you what page, product, or feature to build — apply the guidance below to whatever interface you are already working on, at whatever scope that work requires.
What “Bento” means here
Bento organizes content into a mosaic of rounded tiles at different sizes, packed tightly into a filled rectangle with an identical gap on every side — the arrangement of a compartmented lunch box, which is where the name comes from. Its purpose is to make a lot of separate things scannable at once: instead of a long scroll of sections, a viewer sees the whole set in a single glance and picks what to read.
The discipline is the one-idea rule. Each tile holds exactly one thing: one claim, one metric, one image, one feature. The moment a tile contains two headings of equal weight, it stops being a compartment and becomes a small page, and the format’s entire advantage disappears. Tile size is how you express importance — a bigger compartment for the thing that matters more — not a container to be filled with more material.
The second discipline is that the mosaic must actually be full. A bento arrangement with holes in it reads as a broken grid rather than a designed one, and fixing that with automatic dense packing is not an option: it makes what a viewer sees diverge from what a screen reader announces.
Recommendations
- Define the grid explicitly — column count, row count, and the span of every tile — rather than letting tiles flow and land where they may.
- Vary spans meaningfully. If every tile is the same size it is a card grid, not a bento; give the most important item two columns or two rows and let the rest fit around it.
- Put one idea in each tile. If a tile needs two headings, it is two tiles.
- Use one corner radius for every tile, generous enough to read as a compartment — eight pixels or more.
- Keep the gap identical horizontally and vertically. An uneven gap is what makes a mosaic look accidental.
- Fill the rectangle. If a hole appears, resize a neighboring tile or promote something into it; do not leave the gap and do not turn on dense auto-placement.
- Make each tile self-contained: its own heading, its own meaning, understandable without reading its neighbors. Viewers do not read a bento in order.
- Order the tiles in the document the way you want them read, and let the visual order follow. Explicit placement keeps those two the same.
Avoid
- Uniform tiles at a single size, which is a card grid wearing the name.
- Two headings of the same level inside one tile.
- Different corner radii or different gap values across the mosaic.
- Empty cells left inside the mosaic’s bounding rectangle.
- Dense automatic packing, which makes visual order diverge from document order.
- Tiles whose content only makes sense in sequence with the tile beside them.
How to check your own work
Before considering the result finished, look at it and ask:
- Are all the tiles the same size? If so, nothing is being said about relative importance and the format is doing no work.
- Does any tile contain two things I would describe separately? Split it.
- Is there a hole anywhere inside the mosaic’s rectangle? Fill it by resizing, not by packing.
- Read the tiles in document order with the visuals hidden. Is that the order they appear on screen? If not, the layout is reordering content and that has to be fixed at the placement level.
- Pick any single tile and read it alone. Does it still mean something? If it needs its neighbor, the content is not compartmented yet.
Specification
Bento — Specification
Definition
Bento is a web-interface layout style that arranges content as a tightly packed mosaic of rounded tiles at varying spans, filling a rectangle with a uniform gap on every side. Each tile carries exactly one idea, and tile size expresses relative importance. Its purpose is to make many separate items scannable simultaneously rather than sequentially.
Core principles
- One idea per compartment. A tile holds a single claim, metric, image, or feature; two ideas mean two tiles.
- Size communicates importance. Span is the mechanism for emphasis, not a container to be filled with more material.
- The mosaic is full. Holes inside the bounding rectangle read as a broken grid rather than a composed one.
- Explicit placement. Every tile’s span and position is declared, which is what keeps visual order identical to document order.
- Tiles stand alone. Each is understandable without its neighbors, because a bento is not read in sequence.
Visual characteristics
- Rectangular tiles of varying width and height packed into a filled rectangle.
- A single, generous corner radius shared by every tile.
- An identical gap horizontally and vertically between all tiles.
- One heading plus its supporting content inside each tile.
- No empty cells within the mosaic’s bounds.
- Larger tiles for higher-priority items, surrounded by smaller ones.
Rules
-
Explicit grid with varying spans. The mosaic is a declared grid in which tiles occupy different spans. Acceptance criterion: The container declares explicit columns and rows, and at least two tiles occupy different span values.
-
One idea per tile. Each compartment carries a single subject. Acceptance criterion: No tile contains more than one heading at the same heading level.
-
Uniform corner radius. Tiles share a single rounding value. Acceptance criterion: The computed
border-radiusis identical across every tile and measures 8px or greater. -
Constant gap. Separation is even in both axes. Acceptance criterion: Computed
row-gapandcolumn-gapare equal to each other and identical throughout the mosaic. -
No holes. The mosaic fills its own rectangle. Acceptance criterion: No empty grid cell exists within the bounding rectangle of the rendered mosaic.
-
Visual order equals document order. Placement never reorders content. Acceptance criterion:
grid-auto-flowdoes not includedense, and the visual sequence of tiles matches their order in the DOM. -
Self-contained tiles. Each tile is meaningful in isolation. Acceptance criterion: Every tile has its own accessible name, and its content is comprehensible without reading any adjacent tile.
Avoid
- Uniform tiles at a single size, which is a card grid rather than a bento.
- Two same-level headings inside one tile.
- Varying corner radii or gap values across the mosaic.
- Empty cells left inside the mosaic’s bounding rectangle.
- Dense automatic packing, which separates visual order from document order.
- Tile content that only makes sense in sequence with its neighbor.
Acceptance criteria
- Rule 1: The grid is explicitly declared and at least two tiles have different spans.
- Rule 2: No tile contains two headings of the same level.
- Rule 3: All tiles share one corner radius of at least 8px.
- Rule 4: Row gap and column gap are equal and constant throughout.
- Rule 5: No empty cell exists inside the mosaic’s bounding rectangle.
- Rule 6: Dense packing is not used and visual order matches DOM order.
- Rule 7: Every tile has its own accessible name and stands alone.
Blocking failures
- Dense automatic packing is enabled, so the order a sighted visitor sees differs from the order a screen reader or keyboard user encounters.
- A tile’s content is unintelligible without an adjacent tile, which breaks the format’s premise that items can be read in any order.
- Every tile has an identical span, so the layout communicates nothing about relative importance and the format has been applied as decoration.
These conditions make the work unacceptable to ship; they are not stylistic suggestions and are not subject to designer discretion.
Responsive adaptation guidance
- The column count reduces at narrower viewports and tile spans are re-declared for the reduced grid; spans are never left to reflow automatically, since that is what introduces holes and reordering.
- Span variation (Rule 1) must survive the reduction: at a two-column grid, at least one tile spans both columns while others span one.
- The no-holes requirement (Rule 5) is re-verified at every breakpoint, because a span that fits a four-column grid frequently leaves a gap in a three-column one.
- At the narrowest widths the mosaic legitimately collapses to a single column of stacked tiles; Rules 2, 3, 4, 6, and 7 continue to apply, while Rules 1 and 5 are satisfied trivially.