Open Malvoz opened 5 years ago
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
Thanks for the feedback @halvorsanden. word-break
is a separate property though, and thus off-topic.
word-break
)overflow-wrap: break-word
does indeed seem worse than the default:
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. :)
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.
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.meDemo HTML
Copy & paste to open in a browser: ```html
URL: https://example.com/abcdefghijklmnopqrstuvwxyz123456789