[css-overflow-4] Ellipsizing of text in middle of string #3937

Thank you for picking up my proposal, Harrison!

For reference, my proposal actually included two ideas. The first one was to allow cropping in the middle of the element's content and the second, related one to preserve some part of the contents on smaller element widths.

To avoid discussing two features at the same time, let's focus solely on middle-cropping here.

My proposal back then was to reuse text-overflow for this purpose and simply add a third value to it specifying the cropping in the center of the contents. @MatsPalmgren had another proposal in the related enhancement request for Gecko, which let you move the end ellipsis. Both proposals turned text-overflow into a shorthand and introduced different longhands allowing to control the different partial values separately.

Issues with the proposals, which need to be solved:

1. Normally, you will only want to crop either at the beginning and/or end or in the middle, but not both.
2. For middle-cropping you will only want to have ellipsizing but not clipping, so clip should not be allowed for it.
3. Handling of inline contents other than text.

Sebastian

Additional note: The proposal only covers inline content cropping. There might be cases, in which you'd want to do block-level middle-cropping. Though I guess that's rather related to line-clamp.

Sebastian

There might be cases, in which you'd want to do block-level middle-cropping.

Would there? on single line ellipsis, doing it it the middle makes sense to me, but on multiline, it seems a lot less useful. Maybe I'm just short on imagination. Do you have examples of when you'd want that?

I would appreciate this feature as well. macOS Finder uses an inner ellipsis likely because the most variation and differentiation in a filename is at the beginning and end of the filename.

<div class="mete">
  <span class="mete-start">When rendering this long sentence&nbsp;</span>
  <span class="mete-end">you will often see a middle ellipsis!!!</span>
</div>

.mete {
  display: flex;
  align-items: baseline;
  justify-content: center;
  height: 1.5em;
  line-height: 1.5em;
}
.mete-start, .mete-end {
  overflow: hidden;
  height: inherit;
  flex: 0 1 auto;
}
.mete-start {
  word-break: break-all;
}
.mete-end {
  white-space: nowrap;
  direction: rtl;
  text-overflow: ellipsis;
  text-overflow: ' ...';
}
.mete-end::after {
  content: '\200E';
}

Here's the utility I use to solve this gap in the spec. But it does have the caveats of not working in webkit, misusing direction, and being tricky to semantically style (em/strong) text across the center boundary, but it is selectable and mostly accessible. :/

https://jsfiddle.net/t5jvns7q/

There might be cases, in which you'd want to do block-level middle-cropping.

Would there? on single line ellipsis, doing it it the middle makes sense to me, but on multiline, it seems a lot less useful. Maybe I'm just short on imagination. Do you have examples of when you'd want that?

Well, the cases are not as strong as the single-line cases, I guess. Though the principle stays the same, i.e. cases, in which you care more about the ending than the middle of the contents.

One use case could be the Inspector panel within browser DevTools, which shows the text contents of the elements. When they span over many lines, it gets quickly hard to skim over the HTML structure. Those could limit the contents to a specific number of lines but crop them in the middle of the contents, so it's easy to skim over them.

Example:

Could be shrinked to someting like in this mockup:

Sebastian

Giving the issues stated earlier some more thought, I came up with another approach than outlined in my first suggestion.

• Normally, you will only want to crop either at the beginning and/or end or in the middle, but not both.

We might introduce a text-overflow-position longhand to cover that.

• For middle-cropping you will only want to have ellipsizing but not clipping, so clip should not be allowed for it.

Some possible options to handle this:

1. Introduce an auto value and make it the initial value. For start and end positioning of the overflow handling, the used value would then be clip, for middle positioning it would be ellipsis. (That requires checking web compatibility.)
2. Let clip also apply to middle positioning. (Though clipping the inline content in the middle probably doesn't have any use cases.)
3. Interpret clip for middle positioning as ellipsis. (Might be unexpected.)
4. Interpret clip for middle positioning as if end positioning was applied. I.e. clip the contents at the edge where they overflow the element.

• Handling of inline contents other than text.

This would work very similar to the current definition. I.e. characters and atomic inline-level elements would be removed until the ellipsis fits.

With an auto value as suggested above, the syntaxes might then look like this:

text-overflow = <'text-overflow-handling'> || <'text-overflow-position'>
text-overflow-handling = auto | [ clip | ellipsis | <string> | fade | <fade()> ]{1,2}
text-overflow-position = [ start || end ] | middle

With names to be bikeshedded, as always. And only the first handling value would be applied if middle positioning is chosen.

The simplest middle-cropping could then be achieved via text-overflow: middle. Some advanced examples would be text-overflow: middle fade(3ch) and text-overflow: start end ellipsis.
Doing so, we'd have to define what to do in cases like text-overflow: end start ellipsis fade.

Sebastian

The initial suggestions celebrated 10 years anniversery yesterday. 😄
Maybe we can discuss the latest suggestion while we're at the F2F.

Sebastian

The CSS Working Group just discussed [css-overflow-4] Ellipsizing of text in middle of string, and agreed to the following:

• RESOLVED: Start work on middle ellipsis in css-overflow-4

For what it's worth, one thing I was going to add to the discussion regarding bidi is that my intuition about real bidi usecases (which are different from the testcases we write!) is that real bidi use cases generally have a dominant text direction and small pieces of text in other directions.

I think that might make me lean towards the idea that visual is fine for the middle like it is for the ends, but I'm also not really an expert on the use cases...

There might be cases, in which you'd want to do block-level middle-cropping.

Yes, the vue-clamp component implements the ellipsis position, which takes values 'start' | 'middle' | 'end', this on github currently has close to 700 stars. cc @Justineo

https://vue-clamp.vercel.app/#demo

Another case we have in Proton Drive: we want to keep the last characters to display the extension of a file (with long filename, for security reasons)

We did implement a solution by splitting the filename thanks to this component https://github.com/ProtonMail/WebClients/blob/main/packages/components/components/ellipsis/MiddleEllipsis.tsx but when we have a mix of RTL/LTR, it's a nightmare.

A native solution with an offset would be really helpful there :)

EDIT: some explanations of the issues => https://www.smashingmagazine.com/2022/12/deploying-css-logical-properties-on-web-apps/#mixing-rtl-and-ltr-content