Media Queries, Frameworks & An Eye for Design

Media queries have been around for almost 10 years and now that I think about it, that’s a real long time, especially on the web. I still remember the first responsive site I’ve built in 2010 like it was last year. It was seven years that said website had been launched and was to be redesigned. It for sure served well, but I’ll keep that for another story.

Back in 2010, we used to write our CSS from max-width media queries down towards mobile. As many will remember, or at least know better now, this approach didn’t work too well. To avoid unnecessary overwrites, the concept of mobile-first^{^1} was born.

There were fluid, fully responsive and adaptive layouts. I think the style that has been prevailing for a long time has been adaptive layouts. It might still even be today.

Since the introduction of responsive web design with media queries and the (rather slow) rise of responsive sites, my guess is that adaptive layouts were the ones used most often. Somehow fully fluid layouts had the reputation of being more difficult to achieve, mainly because it probably was a little more difficult. Not more difficult in terms of technical complexity, but fluid layouts required a different thinking and a bigger mental shift. And only few wanted to take this on, embrace the new paradigm, and dive in to fully commit.

By that time we had built websites with pixel values and fixed width layouts for 10 to 15 years, and as we all know, a change is always more difficult than to do what one has always done.

Even though there has been so much happening in the web technology space and how the approach to building sites (or webapps therefor) has changed, one thing has bothered me for many years:

Media queries are underused, underrated and somewhat misunderstood.

CSS doesn’t get a lot of credit these days. CSS is “not a real programming language”, hence too easy to be taken seriously, and yet it is difficult enough to be too hard to learn. Believe it or not, even after many years, responsive web design is still hard. I think that this very fact is one of the main reasons why people like to use frameworks instead of building what they need or want from scratch.

So many sites, and many frameworks, set their breakpoints by device viewport widths. To narrow it down, the most common breakpoints are 480, 600, 768, 1024 and maybe 1280px^{^2}, but that might already be pushing it a little… there’s not so much wrong with this approach at first, but what happens with many sites is that the design changes in “radical” ways at said breakpoints, even though there would have been much more room to adjust. I think my most unliked thing to see is the main site navigation change to a hamburger menu just below a 1000px viewport width. Because that’s what the framework does. If you then don’t understand the underlying technique to be able to change and adjust things to your liking, this forced-upon-you solution will be the one for you. Not because it’s right or the best solution out there, but merely because that’s what it is.

Another thing that still persists and I still hear quite a lot is that extra breakpoints are extra effort and do cost extra. This is probably part philosophical and part knowledge issue. I believe the biggest misconception of media queries is that in many cases they are seen as a site-wide “configuration”. I believe it’s gotten less with the conversations around component-based design, yet it requires a good understanding of CSS, which doesn’t happen to appear by talking about components, though conversations and thinking in components definitely supports it.

Components in the technical sense also don’t matter so much in this context. If you have a navigation bar, it’s a “component” of your page, no matter how it’s built, re-usable or not. I always wanted these components—or let’s say every part of a page—to look great and as close to perfect as possible on every device and every viewport width.

Of course it always depends on the content of your component and that’s why any framework will always only be a somewhat close approximation to what you want to achieve. It’s been built for other peoples problems, not your specific one. Fair enough, that’s why they’re a great starting point, a great resource to learn and helpful to quickly get a prototype out the door.

To polish components and make them work everywhere the way I want, I have sometimes used many different media queries for a single component. Media queries can (and IMHO often should) differ throughout the page for different components, parts, etc.

In other cases it can be quite tricky to achieve desired outcomes with media queries, e.g. when nested components in different contexts get on stage. (This is exactly why we want container queries…) Luckily and thanks to CSS grid and flexbox layout modules it's sometimes possible to achieve the perfect outcome with very few or no media queries at all. Some great examples and approaches can be found on Every Layout.

I want to come back to philosophy. If you want to build high quality interfaces that work well across devices and look great everywhere, you’ll have to go that extra mile. You can’t whine about too much effort. As a designer (and developer) it’s your job to make things look good. It’s your job to make it awesome. At least make it as good as you can. Whether that requires more media queries, element queries or the latest, greatest future-voodoo-magic, then those are the tools for you to deliver your best work. And you will charge for the great work you do, and not the amount of media queries that you had to write.

https://foobartel.com/@/page/itGCqDURUsFfC5B8