overflow-wrap: break-word

[Malvoz]

Personally, I default to use html { overflow-wrap: break-word; } (https://www.w3.org/TR/css-text/#overflow-wrap-property) specifically to allow wrapping of long text strings such as displayed URLs. I haven't observed any issues with this, but I can imagine there may be unexpected behavior with mixing certain writing-modes or some such.

See this anonymous glitch for a quick demonstration:
https://pool-highfalutin-pickle.glitch.me

Demo HTML

Copy & paste to open in a browser:

<style>
  /* Simulate a viewport size that is smaller than a long URL embedded on the page */
  viewport-size {
    display: block; 
    width: 320px;
    font-size: 16px;
    border: dotted 2px;
  }
  input:checked ~ viewport-size {
    overflow-wrap: break-word;
  }
</style>
<input id="overflow-wrap" type="checkbox">
<label for="overflow-wrap">
  Set <code>overflow-wrap: break-word</code>
</label>
<viewport-size>
  <p>URL: https://example.com/abcdefghijklmnopqrstuvwxyz123456789</p>
</viewport-size>

[halvorsanden]

Maybe classify it as secondary or specialized, if at all.

I don't recommend using this on anything but carefully selected elements that might contain long strings. URLs are a great use case, so I typically only set this on body text containers and headers. URL strings rarely exist in other places of a UI, which makes setting this on html overkill.

It also has the potential to break even two-letter words (like in buttons). Especially if working with fixed sizes (for some reason). I have seen examples where this and/or word-break: break-word; (which is stronger/worse) have been used as resets and people who have added it as a dependency (for some reason) have ended up having to write a remedy for the remedy. I made a codepen with some edge cases: https://codepen.io/hwsanden/pen/mddrVwb?editors=1100

[Malvoz]

Thanks for the feedback @halvorsanden. word-break is a separate property though, and thus off-topic.

Considering your example (without word-break)

In your example usage of fixed-width buttons, overflow-wrap: break-word does indeed seem worse than the default:

html {
  overflow-wrap: break-word;
}

.fixedbtn {
  width: 3rem;
}

html {
 /* overflow-wrap: break-word; */
}

.fixedbtn {
  width: 3rem;
}

While we could take out the letter "t" from the word "not" and call it the day, what developers really should do is tailor their CSS for the given content. For example, what if that text was something longer, say "Accept cookies"?:

html {
 /* overflow-wrap: break-word; */
}

.fixedbtn {
  width: 3rem;
}

At this point, you'd probably increase the width (while min-width is really the better option to begin with):

html {
 /* overflow-wrap: break-word; */
}

.fixedbtn {
  width: 5rem;
}

And the result is the same with overflow-wrap: break-word:

html {
  overflow-wrap: break-word;
}

.fixedbtn {
  width: 5rem;
}

It seems to me that no harm has been done by using overflow-wrap: break-word.

The example focuses on an edge use case, where it seems that issues arise from a less ideal CSS practice of using fixed width for buttons (or otherwise small containers), considering that users can increase font-size in the UA settings, but also translate the web page - potentially breaking a lot of things (as we're not allowing things to break becuse we're not using overflow-wrap) where the corresponding word(s) in their language is longer than in English.

I may have analyzed the use case incorrectly, so I appreciate any thoughts to it. :)

[halvorsanden]

You're absolutely right about word-break. That's not what this is about.

In the case of the fixed button sizes, which I think we can agree on is rarely a good idea, there's probably little difference between overflowing and wrapping a word. Both break the layout in some form and neither looks good. Although a non-breaking word might be a bit easier to read, most people are probably able to piece together the letters of a broken word.

And so I agree that overflow-wrap: break-word doesn't cause any harm to small pieces of text, but I don't see it as an improvement either. Text inside small containers will break at some point. And it boils down to what one considers being worst, either based on preference or the UI itself – and that makes this an opinionated property. I don't hesitate using it on body text if that exists within what I'm making, but I don't want to risk having to debug and counter the results of this as a global default.