Ahmad Shadeed nails it again with “Defensive CSS.” The idea is that you should write CSS to be ready for issues caused by dynamic content.
More items than you thought would be there? No problem, the area can expand or scroll. Title too long? No problem, it either wraps or truncates, and won’t bump into anything weird because margins or gaps are set up. Image come over in an unexpected size? No worries, the layout is designed to make sure the dedicated area is filled with image and will handle the sizing/cropping accordingly.
There is no such thing as being a good CSS developer and not coding defensively. This is what being a CSS developer is, especially when you factor in progressive enhancement concepts and cross-browser/device unknowns.
A good designer would have already provided any and all possible scenarios with visual references for development to use. Of course, if a designer isn’t available then it would likely fall to dev, but ideally, these are decisions Dev shouldn’t be making blind.
I half agree. It’s great to have a designer that’s very aware of all these possibilities and designs them into mocks. But there are a lot of edge cases and I’d say it’s not a front-end developer’s job just to be a robot that interprets mockups identically and doesn’t think for themselves about these situations. I’d almost rather the designer not waste too much time on designing every possible defensive state, leave that to me, and then we’ll review and discuss once it’s an interactive prototype.
There’s a lot of “should” in this comment, though. I would be thrilled to meet a designer who accounts for every possibility of content conditions in their designs—in reality, I get Lorem Ipsum and un-optimized assets in a badly-organized Sketch file.
I think it’s more than worthwhile for a developer to at least have a toolkit of techniques for handling unexpected dynamic content, even if the designers are doing everything right and providing for that 43-word, 300-character headline.
Realistically, no matter how well Designers anticipate needs, and Developers implement defensively, we cannot prevent poor utilisation.
Just like part of addressing Accessibility is working for Plain Language, which is done in the Content Phase, a good portion of Site “Design” happens after the infrastructure is built. Content Creators and Content Designers need to make good choices.
It is difficult to impossible to code for Image Size AND guess where in an image the Focus Of The Content will be. It is on Content People to know where an Image’s main value lies, and to use appropriate images, or adapt the images with intelligent borders/fills.
The way a Site looks is as much on those who decide what goes on the Site, as it is on those who have designed and built its structures.