This is great. Loads of great examples, and the author has a huge in depth knowledge of CSS. I also had no idea default min-width in flex layouts is effectively min-content. It makes sense, but definitely can cause issues like mentioned
You can save a lot of headaches by forcing thoughtless designers to use texts with different lenghts.
Everyone can make a nice design with lorem ipsum. Making a design that actually works well is a skill.
From time to time I've seen in here, even today in 2023, people in the comments arguing against using CSS as the way to manage layouts in web (like in a post a few days ago about the complexity of CSS of this days - I guess they want us to go back to use HTML tables?) but the whole message with all of this stuff many of us have been doing instinctively is that CSS is not only the meant way to do layouts and all web design and styling, but used appropriately, can save people lots of headaches in the future.
> I guess they want us to go back to use HTML tables?
I don't know what "they" want, but I do know that back when tables were used, there seemed to be fewer problems. I assume that's because using tables is simpler to do and understand. CSS, of course, is more powerful.
Back when we did table layouts, responsive design wasn’t a thing; we were only building for one width. The additional perceived complexity in modern CSS comes from fluid layouts, not the implementation. If you’re building a non-responsive site, you’ll have fewer problems with flex/grid than tables.
Seemed like most of the examples would just be due to sloppy implementation / a lack of testing edge cases? This is a good lesson to take away I guess, but "defensive CSS" isn't how I see it. It just sounds like thoughtful, intentional, and correct CSS is what's missing in those examples.
Maybe this is obvious to me from having built website builders and themes for them, but when making a product that displays unknown, potentially user-generated content, it's to be expected that the content will be different from the boilerplate designs. Working around edge cases like image aspect ratios and words/sentences of varying length are a core part of the UI's development process.
Defensive as in defensive driving, I assume, which would also be better described as thoughtful, intentional, and correct driving. The metaphor follows for me.
There's never enough time to test everything. Problems like text length are pretty much guaranteed to happen, so you may as well code "defensively" for it from the beginning.
Is catering for edge cases something that people need to be made aware of? I find myself asking this question every now and then when I encounter this concept of content not working with design (especially when browsing on Amazon and seeing 24 results on a page that displays rows of 5 elements)
How about catering for (from top of my head):
- n elements in group (min vs max - ie top menu will always have at least one element, max element it can have is 10)
- element defining properties that are always present and not (if we have Product box that Product will always have title; it might not have description, stock indicator, image etc)
- width / height reserved for display of given element (each element reserves this width and this height, ie amount of products in basket is reserved to 20px / 20px irregardless of elements in basket)
There’s two interpretations of this that are possible, one of which is very dangerous:
When making styles for dynamic content, CSS should accommodate a decent variety of possible text lengths and image sizes.
This is obviously a good thing.
The improper interpretation is to write CSS so it’s future proof. Don’t do this - you don’t know what future will happen. Solve the problem you have today, cleanly. If someone else comes along and has to edit your CSS and sees all of this extra rules for a problem that doesn’t exist, they’re going to have a hard time knowing what they can and can not change. In general CSS test coverage is especially poor, and so it’s much easier to edit if all CSS is useful.
15 comments
[ 3.4 ms ] story [ 40.6 ms ] threadI don't know what "they" want, but I do know that back when tables were used, there seemed to be fewer problems. I assume that's because using tables is simpler to do and understand. CSS, of course, is more powerful.
True. As I said, CSS is more powerful. It's too bad that I think responsive design is a terrible thing, though.
Maybe this is obvious to me from having built website builders and themes for them, but when making a product that displays unknown, potentially user-generated content, it's to be expected that the content will be different from the boilerplate designs. Working around edge cases like image aspect ratios and words/sentences of varying length are a core part of the UI's development process.
How about catering for (from top of my head): - n elements in group (min vs max - ie top menu will always have at least one element, max element it can have is 10) - element defining properties that are always present and not (if we have Product box that Product will always have title; it might not have description, stock indicator, image etc) - width / height reserved for display of given element (each element reserves this width and this height, ie amount of products in basket is reserved to 20px / 20px irregardless of elements in basket)
When making styles for dynamic content, CSS should accommodate a decent variety of possible text lengths and image sizes.
This is obviously a good thing.
The improper interpretation is to write CSS so it’s future proof. Don’t do this - you don’t know what future will happen. Solve the problem you have today, cleanly. If someone else comes along and has to edit your CSS and sees all of this extra rules for a problem that doesn’t exist, they’re going to have a hard time knowing what they can and can not change. In general CSS test coverage is especially poor, and so it’s much easier to edit if all CSS is useful.