Sometimes you just have to clip user-generated content, though, because you can't tell the user to "make sure the label succinct enough to fit in this menu." The user will do as they please, and the layout must adapt or break. What alternative is there?
Sure, you could limit the length of the user-generated label ahead of time. But that'll only work for one combination of font-face and root font-size. The user-agent can override the font-face and the root font-size, potentially causing your layout to break. So, once again, you're left with two options: clip the text, or let your layout break (text wrapping where it shouldn't, overflowing text, etc). At least with `text-overflow: ellipsis` if the user-generated label _doesn't_ overflow, it doesn't get clipped.
This is an application logic concern.
If the application did not impose a character limit, or imposed a large one, the design must accommodate this freedom.
Without knowing the rendered width of the text string, you can't limit the text ahead of time. Or are you saying that all designs that can't accommodate text-wrapping should be avoided?
The HTML default is to flow elements to make space for larger conent. You need to go out of your way to break that.
If the subject line were wrapped, which would be nice at times, you’d lose this ability: you’d have to guess the approximate height of each element, and your scroll positions will be imprecise and you’ll have to make messy adjustments from time to time. Overall it generally won’t be too bad so long as there’s not too much variation in them, but it’s definitely still inferior.
You can then read the full subject line and other truncated fields either by opening the email, or by hovering, as the full text is set as the tooltip. And here’s a general tip for others: if you do ever automatically truncate overflowing text, you should set the element’s tooltip to the full text.
—⁂—
¹ Browser do have limits on how large you can make containers, and handle excess in different ways. IE had the lowest threshold of failure at around ten million pixels, beyond which point it would ignore values; the workaround I implemented in https://github.com/fastmail/overture/commit/8d01c74d8c5d4ae0... came as a direct result of a customer reporting that scrolling was broken in IE in their mailbox with a couple of hundred thousand emails. Firefox breaks a little after 2²⁴ pixels, also ignoring values, so it’s still covered in https://github.com/fastmail/overture/blob/0c9828a5b77ad14383... (note the IE stuff is gone because IE is dead! :-) ). WebKit-heritage browsers accept larger values, but clamp them to about 2²⁵ pixels. In all cases, the clamping solution means you can’t access the emails at the end of the list. C’est la vie.
Clipping is a good approach to maintaining the interface widget. However, the content still needs to be exposed somehow, such as with a tooltip on hover. Similar to how all "3 days ago" "dates" should show the actual date/time when hovered.
The default interface should be clean and easy, not cluttered, with a more detailed level available on request.
Then we renamed it UX, trying to make both words about the user, and while I have spent less time navigating the post-rename world than I did the pre-rename world, my understanding of both human nature and the tech news cycle tells me that basically nothing changed.
Just like calling it Software Engineering didn't stop people from YOLOing spaghetti code and gambling on musical chairs or an air of obliviousness to get them out of the blast radius.
But breaking designs with too much text can really lower the perceived quality and the readability and navigation. Often you would use a technique like that to preserve a 2d aligned grid/table/cell/matrix/cards like design, where the overall structure is really more about seeing things in context and in relation to each other. Having uniform spacing really helps there. If you break the 2d alignment the overall structure becomes wiggly and distracting.
This sort of thing reduces confidence. I can also say from looking through a number of others that they often lack nuance, and present a solution to a possible problem, without contemplating why that problem arose, and whether the solution is actually the right solution. (e.g. image distortion and background repeat are both a bit weird when you think about them, and the solutions offered are blunt and often not very good with no suggestion on how they could be improved. And flexbox wrapping basically assumes that horizontal scrolling is bad and needs to be fixed, which it isn’t always, but somehow also misattributes the scrolling in the diagram, making it seem as though it’s the flex container that’s scrolling, when in fact it’s just overflowing and causing its parent scroll area, probably the document scroll area, to have a scrollbar, and that is more likely to be problematic if not managed deliberately; but it also completely neglects to mention the more likely problem with flex overflow, which is your items not triggering overflow, but instead being squished narrower than intended, and that is the thing that would actually be worth while describing the solution for—flex-basis and flex-shrink.)
I read this bit and I feel like I'm taking crazy pills:
>In some scenarios, we might need to truncate a text that isn't important for the user, or doesn't affect the user experience.
If that's the case, then what is the text even for?
This is a text based medium, the text is the content, it's the reason the user is here, they're not here to admire the consistent vertical layout. The priorities are entirely backwards.
If I'm reading a list of names like in a contacts app (e.g the example), I find it much easier and a better experience to skim entries if they have equal height and spacing. Having the trailing characters of a long last name being replaced with ellipsis is completely worth it to get the speed of skimming the list.
If I actually need to interact with the person that has the long name I'm going to click their entry and get their full details anyway.
However, I did think this was a handy feature to point out, just probably not the best example.