In a design system, what is the anatomy of a list item, and what should a list's density setting change — and never change?

## The anatomy of a list item A **list item** (or row) presents one item in a vertical collection. Most design systems define it as slots: | Slot | Contents | Registration-portal example | |---|---|---| | **Leading** (optional) | Icon, thumbnail, avatar, or a selection checkbox | Department icon, or a checkbox for bulk-dropping sections | | **Primary text** | The item's name, one line | 'MATH 150 Calculus I — Section 03' | | **Secondary text** (optional) | One or two lines of supporting detail | 'Tue/Thu 13:00 · Room B214 · Dr. Lind' | | **Trailing** (optional) | Metadata, status, a secondary action, or a navigation indicator | '4 cr', 'Waitlisted', or an indicator that the row opens a detail view | Rules that keep long lists scannable: - **Fixed variants.** One-line, two-line and three-line rows with defined heights, so rows of the same variant line up and the list has a steady rhythm. - **Primary text first and short.** If it truncates, the full text must be available, for example on the detail view. - **One primary action per row.** Usually the whole row opens the item; a trailing action is secondary and separately named. - **Leading elements aligned** — to the first line of text in multi-line rows — so the column of icons reads cleanly. - **Selection is explicit.** When rows can be selected, a checkbox in the leading slot signals it, rather than relying on a highlight alone. - **Dividers optional** — spacing alone can separate rows once the rhythm is consistent. ## What density is A **density setting** trades whitespace for the number of items visible at once. Common levels are **compact**, **default** and **comfortable**. It serves two populations: people who scan and compare large collections on large screens, and people on touch devices who need generous targets. ## What density may change 1. **Vertical padding** inside each row. 2. **Row height** for each variant. 3. **Gaps** between leading element, text and trailing element. 4. **Size of the leading visual**, within limits. ## What density must never change - **The user's text size.** Density adjusts space; text size belongs to the type scale and the user's text-size setting. Some systems do use a smaller type step in their densest data views, but no density mode may override the user's text-size setting or drop body text below the system's minimum readable size — a compact list that ignores enlarged text defeats the users who enlarged it. - **Target size below the minimum.** WCAG 2.2 SC 2.5.8 Target Size (Minimum), Level AA, sets a floor of 24 by 24 device-independent pixels with exceptions such as sufficient spacing. Many systems choose larger touch targets as a convention; compact modes are usually offered for pointer input only. - **Contrast** of text, dividers and focus indicators. - **The information itself.** If compact mode hides the secondary line, that content must still be reachable — otherwise density has become a different, poorer view. - **Order and structure.** Items, headings and focus order stay the same. ## Who chooses the density | Approach | When it fits | |---|---| | **Context default** — comfortable on touch, default on desktop | Most products; no setting needed | | **User setting** saved per person | Power users who scan large collections daily, such as registrar staff | | **Per-collection default** | A dense data view next to a relaxed content feed in the same product | The design system's job here is the component contract: which slots and spacings respond to density, and which floors hold. How a theme supplies the spacing values for each density is the theming layer's concern. ## Across platforms Native mobile platforms have their own standard row anatomy — a leading image, a title and subtitle, and a trailing accessory — and their own guidance on minimum touch targets. A cross-platform system maps its slots onto those so a list feels native on each, while keeping the same density floors.