Category Archives: Layout

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) {
  .content,
  .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.

Book: The Modern Web

Book Review: Peter Gasston’s The Modern Web

tl;dr: Peter Gasston’s The Modern Web is a matter-of-fact compendium of essentially all of the relevant current (and some future) front-end web technologies. It’s hard to know something about everything, and it’s that fact that makes this book useful for designers and developers of all skill levels.

Peter Gasston knows a lot of stuff. In fact, he’s one of the three people I consider to be walking front-end encyclopedias. And that certainly shows in his newest book for No Starch Press.

In The Modern Web, Peter takes the role of a tour guide, or perhaps a weird variant of Dickens’ Ghosts of Christmas Present and Future, showing us pretty much all the front-end tech that’s worth knowing about right now. However, that’s a lot, which means he pretty much grabs you by the hand and pulls you through each of these technologies at top speed. This means the book is never boring: just when you get comfortable with a subject, whoosh! You’re on to the next one. It’s a perfect format for lightly touching on these subjects, each of which might be able to have a book of their own if one went into all the gory details. And he doesn’t shy away from really cool but barely-implemented W3C specs like Grid Layout, either. (Subliminal message from me: We want template syntax. Thanks.)

That’s the main strength of this book. You might know a lot about video, but nothing about SVG or localStorage. This book fixes that. You won’t become an expert in each of the subjects, but it’s surprising how much information Peter packs into each chapter. The book is not really big, but it’s dense. So dense, in fact, it’s easy to miss some of Peter’s dry sense of humor, and his hit-and-run insights, like this one, which is probably my favorite:

“Fast” is the only context that matters.

Brilliant.

The book’s structure is very clear. Each chapter contains a general discussion of a given technology, an introduction to the syntax, and examples. And he tops it all off with notes on browser support for each of the technologies discussed in the book.

This book must have taken an incredible amount of time to research and write, and I think Peter did a fantastic job of extracting the real essence of each spec and presenting it in an easy and quick to read format. Highly recommended for both novice and experienced readers.

Update from The Haystack

Well, hello there!

A lot has been going on around here, and the most important thing is arguably the fact that my book is now available. Responsive Design Workflow is now available through various booksellers, also via responsivedesignworkflow.com. The book, which is quicker and easier to read than it was to write, explains the whys and hows of my basic responsive web design workflow, which I have presented about these past couple of years. It was my privilege to work with some great people behind the scenes, including Mr. Responsive Ethan Marcotte (who wrote the foreword), Jake Archibald (who was kind enough to be my tech editor), and Ana Nelson (author of Dexy, the document automation tool I currently use in my work).

The book site/page, which I’m scrambling to complete, will contain errata (my publisher explained that everyone makes mistakes, not just me, so I’ve stopped torturing myself, kind of) and code examples. In fact, I’ve already put the code examples on GitHub so readers don’t have to be the victim of my insane calendar.

Krijn, PPK and I just finished the Mobilism conference, which according to PPK might just have been the last Mobilism ever. We’ll have to see how that works out. It was a fantastic event nevertheless. I presented about web-based mockups, which are an important part of the responsive workflow.

Coming up in several weeks is CSS Day, a one-day event with eight speakers, each of which will be presenting about a specific CSS module. It might not come as a surprise that I’ll be handling Flexbox, as the layout specs have been my favorite CSS topic since I first presented about them in 2009.

I’ll also be speaking at Generate in London, Breaking Development in Nashville, plus a couple of other worthwhile, yet to be announced events. Also in the works: Responsive Design Workflow workshops! Stay tuned.

As for writing, I’ve obviously found time to write everywhere but here: the book, a feature on style guides (with a tutorial on one method of creating and automating them) for .net Magazine, and I’m now a (generally) bi-monthly columnist for the Dutch industry magazine Webdesigner.

In parallel with the above, I’m still doing client work, although the amount of projects I can do is limited since I started working independently two-and-a-half years ago, which even now still takes some getting used to. I have difficulty with saying “no”, but a heavy workload is good training for that.

There’s a family life in there somewhere. Social life is on the to-do list. :)

Cheers,
Stephen