DEV Community

Cover image for CSS text-overflow Now Takes Custom Text in Chrome 157. Here's What Works (and What Doesn't)
Hannan Shoukat for 8Bit Enterprise

Posted on AI-assisted

CSS text-overflow Now Takes Custom Text in Chrome 157. Here's What Works (and What Doesn't)

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 */
}
Enter fullscreen mode Exit fullscreen mode

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 */
}
Enter fullscreen mode Exit fullscreen mode

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)";
}
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
colinbarnes profile image
Colin Barnes •

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?

Collapse
 
hannanshoukat profile image
Hannan Shoukat 8Bit Enterprise •

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: ellipsis first, 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.