Overflow, wrap and break #
Overflow happens when an element is bigger than its container.
Wrap is when an element continues on the next line instead of overflowing. Text wrapping happens by default at characters like spaces and hyphens, but not inside words. That works in most cases, but sometimes we need to control if and where wrapping should occur.
Break is when wrapping happens inside a word; the word is split.
The CSS #
overflow-wrap: normal and word-break: normal are defaults that make the text wrap at the regular wrap characters. Overflow-wrap properties affect wrapping both outside and inside words. Break properties affect wrapping inside words only. Chinese, Japanese and Korean (CJK) texts are exceptions and will break anywhere by default.
overflow-wrap: anywhere breaks only words that overflow. The word starts on a new line and breaks where it would have overflown. Which means that you risk a bit of space on the previous line. I use this option when I need to break long words, URLs and data without spaces. This works similar to word-break: break-word, but don’t use that, it’s deprecated.
overflow-wrap: break-word breaks similar to overflow-wrap: anywhere, but not at soft hyphens when calculating the smallest intrinsic size. Which means it potentially doesn’t shrink as much.
word-break: break-all breaks all words at the end of the lines. Word length doesn’t matter. All full lines get the same length, but the text becomes harder to read with all the randomly split words. There aren’t many cases where this setting is useful.
word-break: keep-all is only different from the normal setting in that it prevents CJK text from breaking.
white-space: nowrap prevents all forms of wrapping, even at spaces and hyphens. I use this mostly in table cells with numbers. It could also be useful on spans containing numbers instead of inserting non-breaking space in the HTML.
If you come across word-wrap, it’s and old name for overflow-wrap, I recommend updating.
Hyphens #
By default, there is no indication of a word breaking beyond the wrap itself. That can be solved by manually or automatically adding hyphens, but I think they should be used mainly with intentional breaks.
A weird-looking break is often a better option than an automatic hyphen. They can be a source of bugs and human error. Especially in tables and code examples where they add characters that are not part of the data.
Do we need something better? #
Text wrapping on the web might seem far from optimal. But considering the fundamental differences between fixed formats and the web, I don’t think there is a need for a lot of improvement.
Setting characters as break characters would have been nice, for instance when there are underscores instead of spaces. But that is more of a data quality issue. Something that probably should be fixed before the text is part of the HTML.
For automatic hyphens, it can be tempting trying to replicate the level of control found in fixed format publishing – like print and ads. But despite a lot of parameters and hyphen rule lists, this has not been solved there either. No machine can understand words, context and rules to achieve a satisfactory result. Only manual hyphening does that, I know, I have done it on thousands of pages over several books.
That’s also what hyphening on the web boils down to. But instead of targeting words at the end of lines, it’s about adding soft hyphens to long words in case they end up at the end of a line. Beyond that, it seems largely a waste of time. Because hyphens work best when they look intentional. In the wrong place, they look like human error and becomes irritating. Breaking words without hyphens is probably irritating too, but less so because it looks like a necessity and a side effect of the technology.
Scroll or fit #
Overflow and wrapping is another example of how it’s best to make decisions for interfaces in a browser. It’s difficult to know and see how the different options behave if you don’t write them directly. Adding it as a reset/normalize/base quick-fix setting will likely cause bugs because breaks and layouts can’t be predetermined. I’ve seen sites with five-letter word buttons break over multiple lines because of that.
Breaking is a way to get the content to fit inside a layout or the viewport. But the content should be the driving factor for the layout, not the other way around. At some point, it will cause more harm than introducing scrolling.
For tables and large code examples, this happens relatively quickly, and I recommend horizontal scrolling. Being able to convey meaning through words is more important than fitting letters inside a cell or viewport. This calls for flexibility and calculations instead of one all-powerful setting and detail control. Stuff that you have to work with real data in a browser to achieve. I see some also do this on headings, I’m not entirely convinced about that idea.
At the time of writing, there is an upcoming feature text-wrap: balance that can balance the length of headings. It’s generally safe to use, but it can cause some unwanted effects in combination with other wrapping properties. Combining text-wrap: balance and overflow-wrap: anywhere will lead to unwanted wrapping. Browser support is also low. Always consult your site’s browser stats.