But that's only one of the tips, the rest of the tips are about adapting to arbitrary screen size and content without visually breaking?
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.
But what about user-agents that override font-face and font-size? Those are important accessibility features for people with poor vision or dyslexia.
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?
Usually when the layout breaks, functionality is lost: buttons can't be clicked on, text can't be read, content is obscured to the right, etc. If none of these things are happening, I'd agree not clipping is fine.
Do you have any data to back up that "usually"? IME more often than not the only reason why content is clipped is because of looks not because of functionality. This also applies to the example in the article.
The HTML default is to flow elements to make space for larger conent. You need to go out of your way to break that.
A data point may be used in several places in your UI. Why should it be clipped at the application level, if the same string is shown in a headline or list abbreviated and in another place in full?
This is the kind of stuff that gets boiled out of your blood after one day of practical front-end dev work.. Either that or you dedicate the rest of your life to creating a framework to ensure that your, infrequently updated and even less frequently visited, blog to aligns to a vertical grid.
One uncommon place where clipping is justified at the design level: lazy-loading of finite but known-size lists, with a real and correct scrollbar. I’ll use Fastmail’s webmail (on which I worked a few years back) as an example. I could load a list of a hundred thousand emails, and each message in the list is, under my configuration, 88px tall (containing four lines of text—approximately, sender and date, subject, and two lines of preview, with truncation on each), so the list container is made to be 8,800,000 pixels high¹, and I can use its scrollbar to immediately jump to any place, and it will figure out which messages to fetch and render based on the scroll position.
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.
It doesn’t strike me as a problem in a simple list widget as shown in the article. Presumably you can click on the list item to see the person’s full name. That’s just an example of “click or scroll here to see more of this content” which is literally an unavoidable design pattern on any given display.
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.