Archive for the ‘Responsive Design’ Category

File Under: Responsive Design

Embracing the Flexibility of the Web With ‘Responsive Enhancement’

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.

File Under: Responsive Design

‘This Is Responsive’: Everything You Ever Wanted to Know About Responsive Design

Image: Screenshot/Webmonkey

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.

Drink in the Responsive Grid With ‘Bourbon Neat’

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.

To give it a try, just install Neat and its dependencies and check out the guide to using Neat over on GitHub. Be sure to look over the example page to get an idea of what you can do with Neat and how it works. If you’re a Rails developer there’s a Neat gem you can install.

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.

File Under: Responsive Design

Give the Web a Responsive-Design Facelift With ‘Responsive Retrofitting’

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.

W3C Publishes First Draft of HTML Responsive Images Extension

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 draft seeks to find a middle ground between the WHATWG’s proposed srcset attribute for the img tag and what many web developers want — a new <picture> element.

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
  • Provides a purely client-side solution that can include JavaScript, but doesn’t require it
  • 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:

<picture alt="">
    <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
    <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
    <source srcset="small-1.jpg 1x, small-2.jpg 2x"> 
    <img src="small-1.jpg"> 
</picture>

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.

If you’ve got ideas on how to improve <picture>, head over to the Responsive Images Community Group and let them know what you think.