Defensive CSS
defensivecss.dev
defensivecss.dev
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.
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.
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.
However, I did think this was a handy feature to point out, just probably not the best example.
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.
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 see SO many designers/devs that absolutely do not think of these things. The minute the design is being used 'for real' it becomes messy real quick.
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.
Not the same exact link but same author. Looks like he turned his post into a full-blown site.
https://dom-event-to-css-variable.glitch.me/
https://github.com/pseudosavant/dom-event-to-css-variable.js
CSS grid combined with media queries feels like cheating to me. Am I missing something big here, or is this all safe to use in 2022?
CSS Grid + CSS Variables really take CSS to another level.
CSS Grid has been safe for use for a few years now (if you're supporting modern browsers).
https://caniuse.com/mdn-css_properties_display_grid
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 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.
Aside from the Grid-centric lessons, the Grid v Flexbox is worth watching more than once.
I went to the “Introduction To” article but it began reading like a cooking recipe story.
The page is otherwise very elegant.
I’m still holding out for a similar interface builder that can handle responsive design.
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.
So tbh the content looks good for me in both bad and defensive cases
It’s ”defensive” in the same sense as ”defensive programming”: handling possible future / edge cases gracefully.
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.
And if you really want to go all-in with some really deep philosophical questions, I can suggest you the following: Is it possible to center text in a select box? https://stackoverflow.com/questions/10813528/is-it-possible-...