Ok, the first thing I looked at is "long content" https://defensivecss.dev/tip/long-content/
and here they recommend to just clip it. Because who cares about content right? Who cares if the partial content you display is useless, as long as it looks good. And that's the kind of tip everyone here is applauding. I would like to say webdesign is in a sorry state nowawadays, except it was also that way 20 years ago. Maybe this "who cares about the content" attitude is inherent to web designers? Sorry if I sound blasé or cynical, but one gets tired after long enough of this.
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.
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.
I used to say there are two kinds of UI designers: the ones who care about the interface, and the ones who care about the user.
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.
For me the 'more' button doesn't work properly so that's a bummer.
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.
Seems very reasonable to me. The advice is very dubious, but presented as absolute truth with no nuance. That’s bad, and, applying it more generally, if there’s one thing from the first row of tips that’s bad, it’s unlikely to be the only one.
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.)
"Not making content inaccessible" is one of most fundamental principles of front-end work. The famous "CSS is awesome" coffee mug shows the correct default when something is not working like expected: the content is still visible. Defensive CSS should be intended to fail gracefully, and clipping it doesn't do that. (i.e. when it breaks it'll look bad but the content should still be available.)
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.
Most of these are pure common sense if you are apt with CSS.
However, one problem mentioned here is vendor prefix grouping. I've never experienced this problem or seen a grouped prefix ignored by any browser. Autoprefixer doesn't even ungroup prefix rules. I even ran a grouped prefix through W3C validator and came away validated, though the article mentions it's not W3C compliant.
I ran in to this with ::-webkit-progress-bar and ::-webkit-progress-value. Also it turns out you can't animate them, so I had to put the animation on the progress element and manually inherit it on the tree of psuedoelements to get the animation I wanted working.
Show the HTML and CSS for the example in plain text below the example - saves me from firing up the browser inspector tools, which aren't available if I'm browsing on my phone.
The problem is that popular frameworks like Bootstrap and Bulma still don't support CSS Grid (they use flexbox only for layout).
It's ironic that developers have rightly complained how cumbersome CSS layout has been in the past. Now we have CSS Grid - and yet developers still aren't using it.
I think the "issue" is that CSS grid is already powerful and expressive enough so that you don't really need something like Bootstrap/Bulma to get in the way. They would simply rename stuff and be a useless middleman. I don't think even utility/functional CSS frameworks like Tailwind do much with CSS grid (not sure). It's that good.
This is my experience so far. Once I felt the total control over layouts at any size, I had zero fears about losing all the other benefits you get with css frameworks. I can figure out svg icons, modals, etc on my own. The #1 reason I used bootstrap up until now is to deal with complex layouts and breakpoints. Flexbox handles most other cases without much drama too.
I am currently running a 100% vanilla JS+CSS stack for a responsive web app. I have never felt this much power before. Everything is so immediate and obvious now.
CSS Grid is that amazing. I hadn't looked into it much for a while because I had already adopted flexbox, but grid is so much better for most scenarios I encounter.
CSS Grid + CSS Variables really take CSS to another level.
Media queries have been safe for over a decade. If you feel uneasy with grids and/or still want to support ancient Internet Explorer versions just use flexbox instead.
It's crazy that there's so much extra cruft when it comes to crafting web interfaces when a CLI is most often the most powerful and easiest way to get a job done. Am I just taking crazy pills?
You’re not talking crazy pills, but the article is about CSS. That’s like saying, “I don’t understand why we have websites at all.” A very small subset of people know how to use a CLI. We’re talking about building visual interfaces for common consumption. Not tools only developers understand how to use :)
Did it, though? I don't think I've used a Delphi/VB-based application like... ever? I've made some myself back in the day and fiddled around with my friend's university assigments, but I can't think of any real world application using it. Maybe you have some examples?
Really love the togglable examples. It's often hard to imagine how a change look and while in a perfect world I'd have time to make a mockup to test each version, well, it's hardly a perfect world so examples are appreciated!
You don't even need to resize the whole browser window - you can use the responsive design mode of your browser's development tools to resize just the viewport of the website you are working on. And it can even emulate touch interfaces to test the relevant media queries.
And resizing the window is also something native application developers should embrace. Always roll my eyes when some game developer says they can only target 16:9 because they don't have other monitors - just make your window mode resizable and drag the corner.
Hilariously they haven't always applied the defences they're promoting - in the "Scroll chaining" example the page will scroll if you over-scroll the example
I constantly struggle with CSS grids when compared to, say, just using Bootstrap. I know Bootstrap comes with a lot of baggage, but the syntactic sugar is just so useful.
CSS3 got approved in 2006 and now we are at the point where we have to treat the language like it's fighting against us. Quality work the consortium has done in the past 15 years, eh?
the fact you can set a CSS version in your code, and have it not act as it did when that version was originally standardized, is exactly what being "defensive" is about. the code you wrote years ago doesn't work anymore because the browsers have decided to do things differently now.
and yet I can run applications from 30 years ago and it will still function as it once did. no hacks or code changes required.
you shouldn't have to "future proof" source code against an outside entity just coming in and breaking it all. especially when it's supposed to be an open standard.
There were also some more subtle behavior changes a few years ago in the way webkit handled unprefixed flex-direction centering properties (align-items, justify-content) together with min-width/min-height attributes, switching from behaving closer to IE11 in this regard to basically emulating Blink. AFAIK neither behavior was really against-spec.
