When most of us see the phrase responsive design we think of Ethan Marcotte’s original definition — fluid grids, flexible images and media queries. While those are the essential elements of responsive design, developer Jeremy Keith says that designing responsively also means approaching your designs with a different mindset.
There’s a video (regrettably not embeddable) of Keith’s talk on “responsive enhancement” at the recent Webdagene conference in Oslo where he argues that, to design responsively, we need to drop our “consensual hallucination” about what a website is. Much as we might like it to be, a website is not a fixed canvas. It’s not the 600px-wide canvas we used in the 1990s, nor is it the 960px-wide canvas that’s de rigueur today. A website has no width and never has.
Part of the reason responsive design sometimes feels foreign is that legacy of thinking that websites are things with widths. As Keith says “we didn’t embrace the inherent flexibility of the web, we didn’t see it as a feature, we saw it as a bug.” And so we built fixed-width sites for what was and still is an inherently flexible medium.
Keith’s talk gives a great overview of why responsive design is actually what the web has always been and how you can embrace that inherent flexibility in the web. It’s a must-watch for anyone interested in building great websites.
Sure, you’ve heard of responsive design. You probably even know the basics — fluid layouts, flexible images and media queries — but actually building responsive sites can be challenging. Not only are there the technical hurdles of defining breakpoints, managing different layouts, resizing images and so on, but just keeping up with the latest and best ideas on how to do those things is a full-time job.
That’s part of why responsive design guru Brad Frost has created This Is Responsive, a one-stop shop of continually updated responsive design patterns, resources and news. The site is the most comprehensive collection of best practices, tips and tricks for responsive design that we’ve seen — definitely bookmark it.
But the best part about This Is Responsive is that it’s on GitHub, which means everyone can contribute.
Head on over and dig through the responsive patterns for site layouts, tables, how to handle menus and navigation, forms, images and loads more. Also be sure to throw the blog’s RSS feed in your feed reader.
For some background on the project, as well as instructions on how you can contribute, check out Frost’s blog post.
CSS grid frameworks are awesome. They simplify development, eliminating a ton of math and letting you focus on what makes your site your site rather than the underlying structure.
Sadly, it’s nearly impossible to create a reusable, responsive grid that doesn’t litter your HTML with grid-specific class names. Even if the non-semantic class names don’t bother you, there’s no getting around the fact that it’s a pain to update and maintain that code.
The solution is to step back from the CSS and turn to a CSS pre-processor like SASS.
That’s what Bourbon Neat does to create one of the easiest to use SASS-based fluid grid systems we’ve come across. The clever name comes from the fact that Neat relies on the Bourbon SASS library and extends it to create a fluid, em-based grid framework.
The project was created by the developers at Thoughtbot.com. Here’s what the docs have to say:
Why another grid framework?
Because we are not happy with other frameworks. We built Neat with the aim of promoting clean and semantic markup; it relies entirely on SASS mixins and does not pollute your HTML with presentation classes and extra wrapping divs.
Using SASS 3.2 block mixins, Neat makes it extremely easy to build responsive layouts… Using the breakpoint() mixin, you can change the number of columns in the grid for each media query and even store these values in project-wide variables to DRY up your code.
The power of Bourbon Neat lies in some new features in SASS 3.2, namely block mixins, which allow you to use the @mixin syntax to “name” media queries. To see how Bourbon is using that feature, check out the source code on GitHub.
Responsive Retrofitting is a fun little project that allows anyone to create a responsive design for any website.
All you need to do is head over to GitHub and install the bookmarklet in a WebKit browser. Now visit one of the supported sites, like Apple.com. Resize your browser window to be very narrow and click the bookmarklet. The result is what Apple.com might look like were the company to create a responsive website (Update: the Apple CSS retrofit is the work of developer Phillip Zastrow, who has more details about the process over on his blog).
Responsive Retrofitting was created by developer Ben Callahan, who cautions that it is “very much in alpha form.” (As such it, regrettably, only supports WebKit browsers for now.) The bookmarklet is an experiment in responsive retrofitting, writes Callahan, adding “it’s a positive response to more negative (but still much needed) critiques of the mobile web like Brad Frost’s WTF Mobile Web.”
Alpha or no, you can contribute your responsive redesigns for your favorite, non-responsive sites — head on over to the Github repo for more info on how to add your own designs.
The web needs a more intelligent way to serve images; one-size-fits-all doesn’t work in an increasingly mobile world.
Web developers need a way to specify images based on screen size, bandwidth and other factors. To help them do that the W3C, the group that oversees the HTML standard, has published the first editor’s draft of the HTML Responsive Images Extension. The proposal is just a draft, but it points to one possible solution for the responsive image conundrum.
The problem is this: No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants images to look good on the myriad screens connecting to today’s web. Developers need to send small images to small screens and large images to large ones. Currently, web authors use a variety of hacks to (incompletely) work around the problem, but to really solve it the web needs new tools.
The new proposed Responsive Images Extension is hoping to be that new tool. The proposal is one of the first community-created specs, coming from the work of the Responsive Images Community Group. The spec is edited by developer Mat Marquis, who represents the Community Group, and Microsoft W3C member Adrian Bateman.
The goal for developers is to have a simple, but backward-compatible way to serve images based on screen pixel dimensions, density, user zooming and bandwidth. For the latter image choice would be left up to the browser.
In addition to those basic requirements, the Responsive Image Extension proposal has other goals:
Fallback gracefully on older user agents
Can be polyfilled effectively
Retains, at a minimum, the same level of accessibility as current img element
Preserves separation of content markup and styling
Supports use cases where authors need to explicitly define different image versions as opposed to simply different resolutions of the same image
Provides a consistent and predictable pattern for delivering alternate media sources based on client context
Supports succinct but understandable mark-up
Put it all together and clearly the HTML Responsive Images Extension has its work cut out for it. Here’s some sample code showing how the proposed picture element might handle all that:
The first line contains a media query aimed at large screens and the uses the srcset attribute to specify two images, one for standard resolution displays and one for high-DPI screens. The second line handles medium size screens, while the third handles smaller screens and serves as the fallback for low-bandwidth situations. The last line uses the standard img tag for older browsers.
It’s a mouthful of markup, but it’s similar to how the HTML5 <audio> and <video> tags work. Unfortunately it’s sufficiently different enough to be confusing. As Philip Jagenstadt of Opera Software notes, “personally, I don’t think it’s a good idea to reuse the syntax of <video> + <source>, since it invites people to think that they work the same when they in fact are very different.” He goes on to add that “this is neither a “yay” nor “nay” from Opera Software, just my POV from working on HTMLMediaElement.”
And therein lies one big problem for the HTML Responsive Images Extension — browsers aren’t on board with it just yet.
For now that’s fine, the draft is, at this stage, just a proposal in search of feedback. If all goes well browser makers will now step into the fray to enumerate their concerns and any potential pitfalls on the implementation side. And there are pitfalls, including potential conflicts with browsers’ “look-ahead” parsers, but hopefully over time those will be worked out.