content-resilience

PurposeLink to this section

Mockups use "Jane Doe", a perfectly cropped photo, and three list items. Production has a 90-character company name, no photo, a count of 1,284,332, a title in German, and a URL with no spaces. This skill defines what content each component must survive and how it behaves at the extremes — before production discovers it.

When to UseLink to this section

• Building any component that renders content you do not control
• Converting a design made with ideal placeholder content
• Supporting multiple languages or user-generated content
• Bugs: overlapping text, blown-out cards, squashed buttons, horizontal scroll on mobile

Core PrinciplesLink to this section

1. Design with a range, not a sample. Every field has a minimum, typical, and maximum. Know all three.
2. Truncation hides information; only truncate what can be recovered. If users need the full value, it must be reachable (title, tooltip on focus, detail view, expand).
3. Some content must never be truncated. Amounts, prices, dates, error messages, legal text, and identifiers users need to match.
4. Layouts give way; content keeps its meaning. Containers wrap, grow, or scroll; they do not clip meaning or overlap.
5. Absence is content too. Missing avatar, missing description, null value — each needs a defined rendering.
6. Quantity changes layout. 0, 1, a few, many, and thousands are different designs.
7. Format for the user's locale, not the developer's.

WorkflowLink to this section

1. Write the content contractLink to this section

For each component, list every piece of dynamic content.

Get real maxima from the database schema, API validation, or production data — not guesses. If there is no maximum, that is a finding: add one or design for unbounded.

2. Choose overflow behavior per fieldLink to this section

3. Handle absence and failureLink to this section

Reserve image space with aspect-ratio or width/height to avoid layout shift, and handle onerror.

4. Design for quantityLink to this section

For every list, grid, tag set, avatar stack, or menu:

5. Handle user-generated and unusual contentLink to this section

Include in fixtures:

• Long unbroken strings: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, long URLs, email addresses
• Emoji and combined emoji (👩🏽‍💻), including in names and initials
• RTL text (Arabic, Hebrew) and mixed-direction strings
• CJK text (no spaces for wrapping)
• Accents and diacritics, including stacked combining marks
• Leading/trailing whitespace, multiple spaces, line breaks in single-line fields
• HTML/markdown-looking input (<b>, **bold**) — rendered as text unless intentionally supported
• Very short values: one character, one emoji

6. Handle translation and localeLink to this section

• Budget 30–40% text expansion for short UI strings (more for very short ones: "OK" → "Aceptar")
• Buttons and tabs grow; do not fix their width
• Use logical CSS properties (margin-inline-start) for RTL
• Format numbers, currency, dates, and relative times with locale-aware APIs (Intl)
• Do not build sentences by concatenation; word order changes

7. Build and run the stress fixturesLink to this section

Create a fixture set per component: minimum, typical, maximum, missing, unusual, and quantity cases. Render them together (story, test page, or visual regression) at the narrowest supported width.

ChecklistLink to this section

• Content contract written with real min/typical/max
• Every field has an overflow rule
• Nothing that must not be truncated is truncated
• Truncated values are recoverable (including for keyboard and screen reader users)
• Long unbroken strings cannot overflow containers
• Every image has a sized placeholder and a failure fallback
• Missing values render consistently
• 0 vs unknown is distinguishable
• Lists designed for 0, 1, many, and huge
• Numbers, dates, currency formatted per locale
• Layout tested with ~40% longer strings and RTL
• Fixtures render together at narrowest width

Common MistakesLink to this section

• Flex children without min-width: 0, so a long name pushes the action button off screen.
• Ellipsis on a price or amount.
• Truncated text with no way to see the rest, or a tooltip only reachable by mouse.
• Fixed-width buttons that clip translated labels.
• Initials fallback that breaks on emoji or single-word names.
• "1000000" rendered raw or "1.2M" with no way to see the exact value where precision matters.
• Relative dates only ("2 months ago") in contexts where the exact date matters (invoices, audit logs).
• Rendering 5,000 DOM rows because the design showed 8.

ExampleLink to this section

Component: notification item

Fixtures and expected behavior:

Implementation NotesLink to this section

• CSS: min-width: 0 on flex/grid children that contain text; overflow-wrap: anywhere for user content; line-clamp for multi-line truncation; text-overflow: ellipsis with white-space: nowrap and overflow: hidden for single line.
• Wrap user-provided inline strings in <bdi> (or dir="auto") inside mixed-direction sentences.
• Use Intl.NumberFormat with notation: "compact" and Intl.RelativeTimeFormat / Intl.DateTimeFormat.
• Split graphemes with Intl.Segmenter for initials, not string[0].
• Put fixtures in stories or a test harness so the extremes are reviewed visually on every change.

Output ExpectationsLink to this section

Produce:

1. Content contract per component — Field | Source | Min | Typical | Max | Empty? | Overflow rule.
2. Absence rules — rendering for each missing/failed content type.
3. Quantity plan — 0 / 1 / many / huge behavior for each collection.
4. Stress fixture set — concrete values, ready to paste into stories or tests.
5. Findings — when reviewing, each break with the case that triggers it and the fix, with file/line.