Prompt and context
An international content site has card headings that leave one word on a narrow line, while long paragraphs often end with an orphan. Design wants a one-line CSS fix, but the page must also support editing, older browsers, and dynamic fonts. Compare text-wrap: balance, text-wrap: pretty, normal wrap, and stable, then propose a rollout.
This question fits frontend, design-system, and content-platform interviews. The key is treating wrapping as layout behavior rather than a fixed width or a JavaScript measurement result.
What the interviewer is testing
A strong answer uses balance for short headings and quotes, considers pretty for longer prose while acknowledging its higher computation cost, and explains that neither value changes an element's inline size or overrides white-space: nowrap. It also covers stable for contenteditable, multilingual testing, static fallback, and accessibility.
Clarifying questions to ask first
- Is the text a heading, card summary, body copy, or editable field, and how many lines are expected?
- Are we preventing orphans, or trying to make line lengths look more even?
- Do the container styles include
white-space, a fixed height, clipping, orline-clamp? - Which languages, font-loading states, and browser versions are in scope?
- Must legacy browsers preserve the same breaks, or is normal wrapping an acceptable fallback?
A 30-second answer framework
“I would choose by content type: text-wrap: balance for short headings, evaluate pretty for prose only when orphan control matters, keep ordinary content on wrap, and consider stable for editable regions. These values change soft wrapping, not element width; white-space: nowrap, fixed heights, and clipping still need separate decisions. I would keep a readable default, enhance supported browsers, and test languages, fonts, responsive sizes, and editing behavior for both visuals and performance.”
Step-by-step deep answer
Step 1: Separate the four strategies
wrap follows normal line-breaking rules, while nowrap disables soft wrapping. balance seeks more even line lengths for short text such as headings and quotes. pretty uses a slower algorithm to improve longer text and reduce orphans. stable targets contenteditable, keeping earlier lines steadier while the user edits.
Step 2: Give headings a controllable boundary
Balancing needs real wrap opportunities. Set max-inline-size or a sensible container width before applying text-wrap: balance; a one-line string has nothing to balance. Avoid manual <br> breaks for English or Chinese because translations, fonts, and viewport width change the result.
.card-title {
max-inline-size: 24ch;
text-wrap: balance;
}Step 3: Use pretty deliberately
pretty is suitable for body copy, explanations, and longer quotes, but it needs more computation than ordinary wrapping. Use it where text quality justifies the cost and avoid a universal selector. For one- or two-line headings, balance is the more direct choice.
Step 4: Resolve white-space and clipping conflicts
white-space: nowrap explicitly asks for no wrapping, which conflicts with balancing. Remove or override it before expecting balanced lines. Fixed heights, overflow: hidden, and line-clamp can still clip text, so the product must decide whether to grow, show an ellipsis, or expose the full text.
Step 5: Understand the performance boundary
The browser tries multiple line-break solutions. MDN and Chrome documentation recommend keeping balance on short text and considering pretty for longer prose; do not claim either is always faster than JavaScript. Measure layout, font loading, and long-list rendering on real devices.
Step 6: Cover languages and font changes
The same heading has different break opportunities in Chinese, English, German, and Arabic. Test language switches, fallback fonts, zoom, narrow screens, and wide screens. The contract should be no overflow, readable hierarchy, and complete content, not one language's exact line snapshot.
Step 7: Choose stable for editable content
When a user edits the middle of contenteditable, reflow can move lines near the caret. text-wrap: stable can keep lines before the edit steadier, but it is not a heading beautification strategy and does not manage field height. Use it only where editing stability is the actual problem.
Step 8: Design progressive enhancement and verification
Start with ordinary wrap and a height that can grow; add balance or pretty where supported. Layer the enhancement with capability-aware CSS and keep critical content usable without it. Verify computed styles, overflow, CLS, long-list cost, font paths, and screen-reader order.
Trade-offs and boundaries
balance improves the visual rhythm of short text but does not shrink the element; card borders, shadows, and alignment still come from the container. pretty can improve prose while adding layout work. Neither replaces editorial choices, line-breaking rules, overflow-wrap, or an accessible full-text expansion.
Do not treat current browser support as a permanent guarantee. CSS Text Level 4 still has implementation differences, so test the product matrix. Keep a normal-wrap path for critical headings and provide an accessible name or expansion for clipped content.
Rollout plan and evidence
Pilot one heading, summary, and body-copy component. Record language, maximum lines, container size, and font state. Use balance for the heading, try pretty only when an orphan problem is reproducible, and evaluate stable separately in the editor. Check overflow, layout shift, and caret stability in Chromium, Firefox, Safari, and required legacy browsers.
Document content type, maximum lines, white-space prerequisites, fallback styles, and measurement metrics. Run visual regression whenever fonts, container widths, or translations change so a single snapshot cannot hide multilingual break regressions.
Common pitfalls and follow-ups
Applying balance to every element
Global use wastes computation and does not improve long prose. Limit it to headings, quotes, and short text that benefits from balancing.
Assuming balance changes element width
It changes soft wrapping only; it does not shrink-wrap the box. Layout and max-inline-size still control the card's inline size.
Ignoring nowrap or fixed height
Those rules can leave text overflowing or clipped. Inspect computed styles before deciding whether wrapping and height growth are allowed.
Treating pretty as a free orphan fix
Better wrapping needs extra work. Measure long lists and low-end devices instead of relying on a single demo.
Why not use balance in an editable region?
Reflow during editing can move the caret area. Evaluate stable for editing stability and reserve balance for read-only presentation headings.