Chrome 157 went stable on November 3, and one small CSS change in it is surprisingly handy: text-overflow now accepts a custom string, not just ellipsis or clip.
That means the "…" at the end of truncated text can be anything you want: " (more)", " →", " [...]".
It's listed in the Chrome 157 release notes. Firefox has supported it for years, since Firefox 9. Safari doesn't support it yet, according to MDN's compatibility data.
I tried it out before writing this. Here's the recipe, plus two things that caught me out.
The basic recipe
text-overflow only works on text that's already overflowing on a single line. So you still need the usual two properties alongside it:
.truncate {
white-space: nowrap; /* keep it on one line */
overflow: hidden; /* hide what doesn't fit */
text-overflow: " (more)"; /* the new part */
}
That's it. The browser cuts the text where it overflows and adds your string at the end.
Add a fallback in one line
Browsers that don't understand the string value ignore the whole declaration. So declare ellipsis first and let the newer value override it:
.truncate {
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis; /* Safari and older Chrome use this */
text-overflow: " →"; /* Chrome 157+ and Firefox use this */
}
Nobody gets a broken layout. They just get the classic "…" instead.
Gotcha 1: it cuts words in half
This was the first surprise. The cut happens wherever the text runs out of room, even mid-word. In my test, " (more)" produced:
Free shipping on every order over $50 unti (more)
The default ellipsis does the same thing, but it's easier to miss with "…". A word like "(more)" or "[...]" right after a broken word looks more like a bug.
Short, symbol-style markers like " →" or " …" hide this best.
Gotcha 2: multi-line clamping ignores it
The common way to show two or three lines and then cut off is -webkit-line-clamp. I paired it with the custom string:
.clamp {
display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: 2;
overflow: hidden;
text-overflow: " (more)";
}
In Firefox, the custom string was ignored and the text ended with a normal "…". MDN's text-overflow page also says the property only affects text overflowing in the inline direction, not text cut off at the bottom of a box.
So this feature is for single-line truncation. I couldn't test Chrome 157's behaviour with line-clamp myself, so check it before relying on it.
What it can't do: be clickable
The string is just text drawn by the browser. You can't link it, focus it or attach a click handler.
So if you want an actual "Read more" that expands the text, you still need a real <a> or <button>. Where the custom string helps is as a visual hint, for example in table cells, card titles or file lists where the full text sits in a tooltip or detail view.
Where I'd actually use it
-
Card and list titles:
" →"hints there's more to see. -
Table cells:
" [...]"reads more clearly than "…" in dense data. - Non-English interfaces: you can use a marker that suits the language.
The quick reference
| Situation | Does the custom string work? |
|---|---|
Single line with nowrap and overflow: hidden
|
Yes (Chrome 157+, Firefox) |
| Safari | No, falls back to your ellipsis
|
Multi-line with -webkit-line-clamp
|
Firefox ignored it in my test |
| Making the marker clickable | No, use a real link or button |
Small feature, but it removes a whole category of "add a custom suffix in JavaScript" code. Has anyone found a good use for the two-value form, where you set a different marker at the start and end of the line?
Top comments (2)
The mid-word cut is what would bug me most, I'd probably stick with a short arrow marker like you said. Does the fallback order matter if Safari ever adds support, or does the later declaration just win like normal?
Yes, it's just the normal cascade. In browsers that support the string value, both declarations are valid, so the later one wins and you get the arrow. Browsers that don't support it throw the second line away as invalid and keep the
ellipsis. So when Safari adds support, it'll switch to the arrow on its own, with nothing to change.The one rule is the order:
ellipsisfirst, the custom string second. If you swap them, supporting browsers end up showing the ellipsis.If you'd rather be explicit,
@supports (text-overflow: " →") { ... }works too, but the two-line version does the same job with less code.