Prompt and context
A content site contains card headings, article summaries, long prose, and editable notes. Design wants short headings to look balanced, prose to reduce orphans, and lines before the caret to remain stable while editing; the team also needs predictable layout cost and older-browser behavior. Explain how text-wrap-style participates in soft-wrap selection and how you would choose, constrain, and validate each value.
This question fits frontend, design-system, and content-platform roles. The key is knowing that it changes wrap selection, not available wrap opportunities, width, or language rules.
What the interviewer evaluates
A strong answer distinguishes the goals of auto, balance, pretty, and stable: default performance, balanced short blocks, slower but better long-text layout, and stable editing for contenteditable. It should also cover line limits, text-wrap-mode: nowrap, language and breaking rules, CLS, compatibility, and measurements.
Clarifications to ask first
- Which content is a short heading, summary, long prose, or editable field?
- Is the priority visual balance, fewer orphans, editing stability, or minimum layout cost?
- What are the content lengths, locales, font-loading behavior, and container widths?
- What layout budget is available for the first screen and a scrolling list?
- Should older browsers keep automatic wrapping or receive a scripted enhancement?
A 30-second answer
“I would tier the values by content: use balance for short headings, consider pretty for important prose within a measured budget, use stable for editable regions, and keep auto elsewhere. These values only choose existing soft-wrap opportunities, so width, breaking, and language rules still matter. I would ship auto as the safe fallback, then measure real multilingual content, list cost, CLS, and editing behavior instead of judging screenshots alone.”
Step-by-step solution
Step 1: Define what changes
text-wrap-style tells the browser how to choose among existing soft-wrap opportunities. It does not make nowrap wrap, and it does not replace overflow-wrap, hyphens, or container sizing.
Step 2: Use balance for short headings
balance tries to make text across a limited number of lines more even, which suits headings, captions, and short summaries. Browsers limit the number of affected lines, so long prose must not assume global optimization.
.card-title {
text-wrap-style: balance;
max-inline-size: 32rem;
}Step 3: Use pretty selectively
pretty favors better overall composition and fewer orphans, but costs more than auto. Limit it to article prose or important marketing copy, then measure long text, font changes, and lower-end devices instead of enabling it everywhere.
Step 4: Use stable for editing
stable targets editing experiences such as contenteditable, keeping lines before the caret as stable as possible while a user types. It is not version history, an undo stack, or collaborative conflict resolution.
Step 5: Handle text-wrap-mode and breaking
When text-wrap-mode is nowrap, text-wrap-style has no effect. Long URLs, Chinese, German compounds, and mixed scripts are also governed by overflow-wrap, word-break, hyphens, and language metadata; design them together.
Step 6: Set layout and performance boundaries
Wrap changes can alter block height, card grids, and first-screen layout. For virtual lists, search results, and server-rendered pages, record layout shift, style calculation cost, and re-layout after fonts load; a fixed-width development screenshot is not enough.
Step 7: Plan compatibility and progressive enhancement
Browsers without a value generally ignore the declaration and keep their default wrapping. Make auto the base behavior and enhance after support detection or a selector. Do not build a per-character measurement script to imitate every algorithm unless the browser target and product gain justify the complexity and accessibility risk.
Step 8: Build multilingual acceptance tests
Test Chinese, English, long German words, Arabic RTL, Japanese, emoji, dynamic fonts, zoom, editing, copy/paste, and content updates. Compare first paint, list scrolling, focus, heading height, orphan count, and older-browser fallback so visual polish does not reduce readability.
Trade-offs and boundaries
balance suits short blocks, pretty prioritizes composition at higher cost, and stable addresses editing line stability; auto is the general predictable baseline. None changes semantics, content, or the set of soft-wrap opportunities.
Typography values should be assessed with container, font, locale, breaking, and responsive rules. Local enablement is easier to budget than a global rule on a high-frequency list or live editor.
Rollout plan and evidence
Pilot one card heading, article body, and notes editor. Record content-length distribution, line counts, fonts, and performance budgets. Keep auto in the base style, then enable balance, pretty, or stable for the matching content type.
Document the rationale, support matrix, long-text limits, language rules, and metrics. Use real content for visual, performance, keyboard, and editing regressions, and retain evidence that the baseline remains usable with enhancement disabled.
Common mistakes and follow-ups
Treating balance as global optimization for any length
Browsers limit the lines they balance, so long prose should not assume every line is equalized. Restrict it to headings and short summaries.
Applying pretty site-wide
Fewer orphans can increase layout work. Pilot important prose and use long-text and lower-end-device data to set the boundary.
Using stable to solve every editor problem
stable only affects wrapping stability. It does not provide undo, collaboration, or caret semantics; the editor still needs its own state and accessibility design.
Ignoring nowrap and locale rules
nowrap makes the property ineffective, while breaking and language metadata determine available opportunities. Test the CSS and locale together.
What if the heading is still hard to read?
Check container width, font loading, line limits, locale, and available wrap points before changing balance, breaking, font size, or copy; repeatedly toggling the wrap value is not a diagnosis.