Category Archives: Responsive

Choosing between min-width and max-width media queries

I’m often asked a variation of the following question:

Should I use min-width or max-width media queries?

The obvious answer is, of course, “yes”. But you know what they’re asking: which of the two is better?

Those for whom responsive design has become second nature might find it an odd question, and will know that the answer is, “it depends”. But having seen lots of responsive design implementations, it’s clear to me that many designers and developers aren’t quite sure. And I’m happy to share my own opinion of what “it depends” means regarding this particular question.

Desktop first and max-width

There’s a decent number of designers/developers that still think of “the desktop” as their primary design manifestation, with other (generally smaller) sizes as secondary; often these appear as afterthoughts, since there can be significant visual clues as to the amount of effort that has gone into these other screen sizes when compared to their desktop counterparts. Often, when one examines the CSS of these sites, `max-width` is the media feature of choice.

This makes sense. If a design is built desktop-first, then all the CSS for the desktop-ish version of the design has been written, and must be overridden with more CSS for any other breakpoints. If a given desktop-ish width is our baseline and we are unwilling or unable to refactor our CSS, then it seems logical to override what is now our base CSS for all viewport widths with those we only want to apply to smaller widths.

This can lead to a situation I’ve often joked about: writing styles only to undo them later. This is an example I often use (assume .related takes the form of a sidebar):

.content {
  width: 60%;

.related {
  width: 40%;

@media screen and (max-width: 37.4em) {
  .related {
    width: 100%;

The above example omits a lot, but I’m sure you get the idea. This approach, when used over a bunch of components, can greatly increase the amount of CSS needed to complete the project. But the main problem is how illogical it is, because when embracing the fact the block-level elements are 100% of their parent by default, then the following makes much more sense:

@media screen and (min-width: 37.5em) {
  .content {
    width: 60%;

  .related {
    width: 40%;

Here, we’re making use of the default state of block-level elements, and overriding them when they need to change from the default. Again, it might seem clear to some readers, but it doesn’t take looking at the source of many websites before you understand why I’m clarifying it here.

Using max-width against your better judgement

There are a couple of reasons why, even when you know better, you might deliberately choose to use an approach similar to max-width approach above:

  1. You’re a developer and you received desktop-only, desktop-first, or other-sizes-as-an-afterthought comps from the designer. How can you know? If you’ve only designed or received designs for desktop-ish widths, this is what you’re dealing with. If you’ve got nice detailed desktop-ish designs with a few “mobile” or “tablet” examples thrown in there, this is what you’re dealing with. In these cases, may the max-width be with you, unless you have a budget and/or schedule that allows you to refactor during development.
  2. You’re making an existing website responsive, and the existing CSS is design baggage you’ve inherited and cannot change, for whatever reason.
  3. You’re compensating for the fact that we don’t currently have element queries, and you’re handling this with CSS instead of using a JavaScript polyfill for a non-existent spec.

So, what’s the best to use?

Here’s my clarification of “it depends” for this particular question. And remember it’s just my own opinion based on my own experiences: look at default display of a given element. If you have to override this default for smaller screens, use max-width. If the default is usable on small screens, use min-width, and only when the element needs to deviate from the default. And of course, I recommend letting the content determine where that happens.

A good example of using max-width to override an element’s default display so that it works better on smaller screens is when using tables. Imagine a table that contains too much content to display in its default form on small screens. One approach might be:

@media only screen and (max-width: 30em) {
  .big-table tr,
  .big-table td {
    display: block;

This turns each row (and cell) into a block on narrow screens. The table can become quite long vertically and more styling is usually required, but it’s often better than the back-and-forth horizontal scrolling that would otherwise be required to read the content.

In this case, it makes all the sense in the world to leave the table in default form, except for in browsers that understand the media query and where the screen is no larger than, in this case, 30em.

Other elements (I would venture to say most other elements) that have defaults that work fine on smaller screens, only need changing when necessary on larger screens; using min-width is then a solid choice.

In short: let element defaults help determine which media feature to use in your media queries.

Thanks to Brad Frost for reviewing this. He also has a post with related topics.

Responsive Design Sameness

Sometimes, when discussions are really interesting, I find it hard not to chime in.

Mark Boulton tweeted:

I wonder if #RWD looks the way it does because so many projects aren’t being run by designers, but by front-end dev teams.

Then the fine Mr. Tim Kadlec wrote a great post, followed by observations from Susan Jean Robertson. There were also a few thought-provoking responses to Mark’s tweet.

Tim and Susan (and others on Twitter) seem to agree that workflow/process—specifically lack of communication between designers and developers—tends to lead to the type of design sameness we’re observing today. I agree that this is a problem for many aspects of the design process; in fact, I wrote a book about it. And with the utmost respect for Mark, Tim and others, I tend to be skeptical that getting designers and developers to work together will solve the design sameness problem. That’s not to say it doesn’t need to happen; it certainly does.

In my experience, most projects are not run by front-end developers, as Mark suggests might be the case. Of course, that’s just my experience. In fact, I observe that front-end devs often get the short end of the stick, basically forced to implement whatever gets thrown on their plate by designers and requirements. In the same way, the visual designers before them in the waterfall process must implement that which has been handed to them by interaction designers, UX designers, or whoever might be in front of them. A slightly longer stick, but still pretty short. This is a workflow problem, and one of the main things I’ve spoken and written about for the past few years.

But this doesn’t necessarily explain why responsive sites share similar visual characteristics.

At the moment I can think of three things that I theorize might be at least as important as workflow, in regards to RWD design sameness:

  • Lack of a solid graphic design foundation
  • Excessive reliance on tools
  • Lack of critical design thinking when copying the work of other designers

Lack of a solid graphic design foundation

Now that design education has fragmented somewhat between “traditional” graphic design and web/digital/whatever design (even though students are often required to take both), I get the feeling that many designers live with the assumption that these are two separate worlds. It’s probably our fault (I know I’m guilty of it): we keep hammering on the differences between design for web and design for print.

But web and print are simply media. Design is problem-solving. Design is—and for the umpteenth time I quote Paul Rand—”the method of putting form and content together”. Contrary to popular web-belief, good web design is not only typography. Web designers need to know how to design. They need a solid foundation in the principles of design. And when they choose their preferred medium, of course there are always specifics that are only relevant to that medium.

A problem arises when designers lack a basic design foundation, yet have a working knowledge of medium-specific design concerns. Lacking the foundation, their creative potential has a fence around it. And, if what Mark says is true and devs are designing, that foundation might be lacking as well. And, no, I don’t mean go read The Elements of Typographic Style and you’re off to the races. Graphic design is a formal, legitimate field of study.

Judging by what I’ve observed while guest-lecturing to web design students, I suspect that tool-based education and reliance on tools and frameworks is partly to blame.

Excessive reliance on tools, frameworks and pattern libraries

Similar to Mark, I’ve often quipped that 50% of the web looks like Twitter Bootstrap. And it shouldn’t be surprising when a good portion of web design education is tool-focused. Photoshop. Illustrator. Web-based answers to Dreamweaver (“but they generate better code!”) that use frameworks as a Foundation for the generated code. (See what I did there?)

No matter how you look at it, tools are just tools. In my book, I present the Tool Rule: it’s not about the tools. Frameworks are prefab. These tools are about execution, not design. Design involves first thinking, then execution. And when one designs for a particular medium, they need not be shielded from the inner workings of that medium. Designers who want to know how to change Bootstrap need to know the inner workings of Bootstrap; have fun switching frameworks down the road. But why hide the web from them behind an abstraction layer? Would designers come up with more appropriate visual patterns if they knew more about what was possible outside the confines of a framework?

Yes, designers must learn tools. Which tools would make them more effective at being able to effectively design for the web: those that teach them about the web, or those that teach them a particular framework? I don’t know the answer; I just have my opinion.

Lack of critical design thinking when copying the work of other designers

Designers copy/steal trends all the time. Sometimes this is mandated by bad clients (“my competitor does this so it must be good”—oh, the logic), and often designers emulate the bits they like from others’ work into their own projects. It’s not only graphic designers doing this, but interaction/UX designers and developers as well. We copy patterns we like. We have pattern libraries. Prefab building blocks to help us work faster. Faster perhaps, but not always better.

Emulation is a part of the evolution of design. And the web, for that matter. But design sameness tends to fade when one forgets all of the existing patterns, all of the Bootstraps, all of the preconceived design solutions. Design sameness fades when designers stop focusing on which solutions for their problem are out there and start focusing on the problem at hand.

Solve that problem, and maybe the solution is exactly what your peer implemented, in the exact same way. But maybe not.

(Thanks to Mark Boulton for reviewing this post.)

Responsive Design Workflow Workshop in Berlin

With Smashing Magazine, I’ll be doing a workshop on Responsive Design Workflow in Berlin on November 11. Here’s why.

My book, Responsive Design Workflow, has been available since mid-April. The content of the book (as the workflow described within it) is not difficult, but the concepts and techniques presented do become more complex as the chapters progress. For those without coding experience, the later chapters require an openness to new approaches and a certain amount of patience. While the reader is practically hand-held through every step, it can take some time and practice to get used to my approach.

The point of the book is not to say, “this is the workflow you should adopt”, but rather to get readers to think critically about their own responsive design workflow and inspire them to change as needed. I do this by describing my own workflow, which while “different”, has been heavily battle-tested in real projects. I simply can’t describe every workflow out there. I also can’t simply write a book about new workflow theory and not give any examples of a workflow that works. So that’s what I did, and readers can choose whether or not my particular workflow is for them.

Some people have been intrigued by what they’ve read in the book, and I generally receive positive reactions about it. That said, I’ve noticed that for some it’s a lot like cookbook: you read it, you understand what’s there, but watching someone cook from it adds a lot to the understanding of it.

Reading something is one thing, but seeing it done and trying it out yourself adds insight and can be the difference between learning and not learning.

To this end, the Smashing Magazine folks and I have teamed up; I’m hosting a workshop on the content of the book. The first one will be held in just a couple of weeks, on November 11, in Berlin. We’ll have a fun and busy day working through things like:

  • Doing content inventories for design comps
  • Making simple and effective responsive wireframes in the browser
  • Gaining insight into content and design by “designing in text”
  • Ease into the responsive design process by making a linear design first
  • Planning and documenting breakpoints by drawing breakpoint graphs
  • How to make web-based design mockups (and replace PSDs as deliverables)
  • How to present your designs to stakeholders
  • How to create self-updating style guides

It’s going to be a fun-filled day! There may be new dates and locations for this workshop in 2014, but this is the only one I’m doing for the rest of this year.

Smashing is putting on a bunch of other workshops in November and December, hosted by the likes of Dan Rubin, Remy Sharp, Andrew Clarke, and more. Be sure to check them out.

So if you’re able, come join me in Berlin!