Text-overflow: ellipsis considered harmful
This post is basically a short addendum to my article about text resize and reflow. I stumbled over some instances of text-overflow: ellipsis the other day and it broke resize and/or reflow.
The whole reason text-overflow exists is to specify the behavior of text once it flows over the container. There could be with and height constraints for a block. Using overflow: hidden makes sure that there is no overlapping text, but it cuts off the text abruptly. Text-overflow: ellipsis1
allows to at least have an indicator that text is missing. But there is no way to make the hidden text visible.
In addition, text-overflow: ellipsis only works on one line text. That means that, to use this technique, you have to constrain the text to one line by using white-space: nowrap. MDN has a good example of the behavior.
There are a few legitimate use cases for this technique. For example, you might have a table with titles and descriptions. To preserve more space for the title, you constrain the description to one line on small viewports to the one-line and you repeat the description on the detail page for this item.
However, I often see it used on items like buttons or even form labels to make them look nicer(?) or when aligning them vertically. But once you change the viewport or resize the text, the end of the text disappears.
This is not the right thing to do. Even if your button might need to accommodate words like “Wagenstandsanzeiger”, seeing “Wagenstan…” is not going to be clear to users. It would be much better to hyphenate the word (using hyphens: auto2
or ­ entities) instead.
And for the visual design: Inline flex and grids give you a lot of control to align text and icons, for example. Don’t constrain the content to fit your design, make your CSS flexible to handle longer words gracefully.
- And other, less well supported values. ↩
- It would be really neat if Blink would finally support languages other than English here. ↩
Comments & Webmentions
Likes
Shares
Replies
I blogged about this:
Nice work, but it’s also a missed opportunity to call it “Text-overflow: ellipsis considered …”
Oh, you missed Eric Meyer's "“Considered Harmful” Essays Considered Harmful": meyerweb.com/eric/comment/c… ;-)
Thanx for writing this! I will wave this article in front of every product owners or designers nose, who wants to cut words with three dots.
(special thanx and +1 for the second footnote!)
I think calling my little note an essay is probably already giving it too much credit 😉
I was shocked when I saw that table the other day. But at least Blink has Web Notifications!!
And there's a short list of such articles at github.com/odino/consider…
As always, truncation is not a content stra…
twitter.com/search?q=from%…
Why shouldn’t I?
To be honest, I never tested it myself, but I've heard several times that it causes issues with some screen readers. (This info might be outdated, though)
I do think ellipsis should be used wisely; ie use
[title]to show the full text, or:hoverto change it to visible. But saying it is harmful goes too far imho, it's like saying margins are harmfull because you can set them to-100vwSo, how do you hover with the keyboard? (And I said that there are some legitimate use cases in the article.)
h…
This is so perf...
Q.e.d
I never came across any issue with it, I’ll look out for them.
Nice and helpful article.
To truncate multiline text one may use something like this:
This is function for LESS prepprocessor, for example.