About a year and a half ago, I wrote about CSS3’s word-wrap property. The angle of the article was the fact that it was a feature that was new in CSS3 that didn’t exist in CSS2.1 and it worked in just about every browser, including old IE.
Well, now that’s all changed, which I discovered while researching additions to my CSS3 Click Chart. The word-wrap property has been removed from the CSS3 spec and other related properties have been added.
Text-Wrap
The text-wrap property “specifies the mode for text wrapping”. Well, that description doesn’t tell us a whole lot, so let’s break down the values.
normal
This is the initial, or default, value for text-wrap. This is what happens when you don’t have any text wrap settings specified, so a value of “normal” is what you see occurring in any given element that has text.
none
This tells the browser that text in that element should not break at all. So if the text reaches the end of the parent container, it will overflow its parent and any overflow settings would handle the text’s visibility.
avoid
This value will still allow line breaking to occur, but this tells the browser to be selective as to where breaks happen. A nice example is shown in the spec in this section which basically shows that the browser will interpret parts of the markup so as to decide where to break lines and where to avoid breaking them.
Browser Support: None that I know of.
Overflow-Wrap
The overflow-wrap property is the replacement for the now-obsolete word-wrap property. The values are either “normal” or “break-word” — the same values that word-wrap uses.
This particular property, like word-wrap, handles what the spec refers to as “emergency wrapping”. The spec explains: “This property specifies whether the UA may break within a word to prevent overflow when an otherwise-unbreakable string is too long to fit within the line box.”
The spec also explains that if text-wrap is set to “none”, then overflow-wrap will have no effect. Also, although this is for breaking a line in the middle of a word, the word will not be hyphenated. More on hyphenation below.
Browser Support: None that I know of.
Line-Break and Word-Break
According to the spec, these two properties have been introduced to help deal with the problems that arise from browsers assuming that lines and words need to break as is common in the English language. For example, in English a browser will not break a line within a word, but only where there is a space or certain punctuation marks. But in other languages, these rules don’t apply.
As the spec explains, although English lines may break at space characters or punctuation, this is not true in other writing systems that don’t use spaces and punctuation. In these writing systems “a line break opportunity is based on character boundaries, not word boundaries”. Thus, line breaks often have to be supressed within certain character combinations.
I honestly don’t fully understand all the values for these properties, so I won’t attempt to expand on them here. And judging by the description, it seems these two properties would be most useful to those dealing with content in languages that require different line breaking rules than that of English.
Browser Support: None that I know of.
Text-Overflow
The text-overflow property defines how to handle text that overflows its parent when the parent’s overflow is set to something other than “visible”. It accepts the following values:
clip
With this value (the default), the text will be cut off and the remainder would be invisible. This happens by default in all browsers now. Keep in mind that in order for this to take effect, the text would have to be inside an element that, for whatever reason, doesn’t allow natural line breaking.
ellipsis
With this value, the text will still be cut off but the fact that it’s incomplete will be indicated by an ellipsis (i.e. three dots “…”).
As shown below, browser support is very good for this property. Old versions of IE did include support, but it seems the implentation has changed and so newer IE uses prefixes. For more on this and a working live example, see this section on the click chart.
Browser Support: IE6+, Firefox 7+, Chrome 1+, Safari 1.3+, Opera 11+
Hyphens
And finally, CSS3 now introduces a hyphens property that can be used to tell the browser whether or not to automatically insert hyphens.
none
A value of “none” tells the browser to never hyphenate, even if break points are somehow defined.
manual
This value is the default and is how browsers naturally do hyphenation. This means that the browser won’t do any hyphenation unless there are hyphenation characters indicated. You can actually do this using the soft hyphenation character, which, inside of a word, looks like this: hy­phens.
auto
With a value of “auto”, the browser will automatically insert word breaks and hyphenation in accordance with the language defined for that page.
Hyphens have some support so you can see a working example with the accompanying code here.
Browser Support: IE10+, Firefox 6+, Safari 5.1+ (all require vendor prefixes; thanks to Hans for letting me know about support in Safari)
Conclusion
Although browser support is not great for these new features, it’s nice to know that in the future we’ll have some powerful tools at our disposal to handle overflow and line breaks in a more fine-grained manner.
What I think is missing is a ‘text-overflow: ellipsis’ that works with vertically-sized containing elements also. For example, if there is too much text to fit into a box with a fixed height, the text that would overflow or be ‘cropped’ would be hidden and the standard ‘…’ appended. Currently this only works for text that overflows horizontally – which is only possible if for words not to wrap :(
Yeah, that’s really what we need. Ellipses are great for single line items like blog titles in a list or something, but for excerpts of text and such the height is the greater concern, not a single line that fits horizontally and ends…
I second that \ :D \
Thanks for the share, I have been reading everything I can find about CSS3 lately.
I did not know that
word-wrapwas removed. Thanks for telling us!CSS3 hyphens are supported in Safari 5.1 but still not in Chrome 18. I’ve made this fiddle to check and blogged about the whole hyphenation thing some time ago.
Hmm, that is really strange. If you compare these two charts:
http://en.wikipedia.org/wiki/Google_Chrome#Release_history
http://en.wikipedia.org/wiki/Safari_version_history
You’ll see that Chrome 16 (the current stable release) is using a newer version of WebKit, yet you’re right — Safari 5.1 supports hyphens, and Chrome doesn’t.
Thanks for the links. I’ll update the hyphens section of my click chart and I’ll post a link in there to your article.
It may be possible that this is an additional feature which is not part of WebKit and Google did not implement it.
I tweeted to Peter Beverloo. Maybe he knows something about this issue.
> it worked in just about every browser, including old IE.
> Well, now that’s all changed…
WHY??? What was the need to drop the well-known, well-documented and widely supported for more than a decade feature in favor of the other, that is exactly the same except of the name, which is much longer and less memorable? As for me, ‘overflow-wrap’ sounds more confusing, making me think first about vertical overflow of the box, while ‘word-wrap’ is directly connected with the handling of long words (to make them fit their wrappings) and looks more descriptive for its result. Why do CSS3 editors believe that ‘overflow-wrap’ “is a better name”? I hope this is not only because ‘word-wrap’ was first introduced by Microsoft?
I can agree that things like flexboxes can change (new suggestions in fact look better than those that had experimental, prefixed support in Gecko and Webkit), but replacing the working feature with the not working one just because of perfectionism seems to be a big mistake. I also hope that the good sense will win and this mistake will be corrected (the well-supported name will be returned) before the spec matures.
Has anyone checked out the Bacon jquery plugin that wraps text on a bezier curve?
http://baconforme.com/
Though it would improve text-align:justify, it would be still not as good as in books as we have no manual control over kerning/tracking, especially if user can resize text.
Word breaking used in books to save space, to make book smaller. There is no reason to make sites smaller because text fit into one page anyway.
Excellent post.
The way this is headed, CSS will soon be it’s own programming language without the need of implementing other scripts in order for a page to display and function beautifully.
Thank you very much!! This was a life saver
thanks a lot.
this is a very interesting website. love when content is updated.
definetly bookmarked.
My project manager is fan of your nav mouse hover effect :-)
W3C validator reports “Property text-wrap doesn’t exist : none”, but you cant use a substitute since there is none.
Yes, I’ve added a note in that section that says it’s no longer in the spec. I don’t think you need it so I doubt a substitute is necessary.
Is there any workaround for display: table-cell in IE9 ? it just doest work in IE9 when elements display is table-cell :(
try this pen in IE9 :
http://codepen.io/ashkanhosseini/pen/xwKqaW
iwastryingtowriteaverylongwordtocheckifthissiteisusinganykindoftextwrapinhiscommentssectionbutidonotverysurewhattowriteinthistextareaihopethattheadmindoesnotremovemycommentthatisverynicethanksforallseeyoulateridonothowtowriteinenglishsorryforthat
I’m trying to fit long file names with:
overflow: hidden;
text-overflow: ellipsis;
width: 70%;
and it works good if the file names are consisted of letters, spaces or “_”, but if there is “-” word breaks in many lines and ellipsis is not implemented.
Is there a way to overcome that?
Thanks in advance :)
You should also include:
white-space: nowrap;
That should fix it.