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.
Show your favorite sites how the small screen is done. (testing responsive sites with Adobe Shadow). Photo: Adobe
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.
So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe
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
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:
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.
Meet Twenty Twelve, the latest default WordPress theme. Image: Screenshot/Webmonkey.
The default WordPress theme is quite possibly the most widely used design on the web; the minute you sign up for or install WordPress you have a website that uses the default theme. Every year WordPress unveils a new look that will grace every “just another WordPress site.”
This year’s theme, Twenty Twelve, is the first to embrace responsive design, adapting its layout to fit any screen. The WordPress admin pages are already responsive, and the last few default WordPress themes have accommodated small screens, even using some responsive design tools like CSS @media, but this is the first default theme to fully embrace responsive design and fluidly adapt to any screen.
Twenty Twelve marks something of a departure for the default theme. Gone are the banners and featured images atop posts. Instead Twenty Twelve sticks with a largely black-and-white look that puts the emphasis on typography and a new typeface, Open Sans.
If you’d like to use Twenty Twelve on your WordPress.com site, just head to the dashboard and select Themes, (under Appearance). If you’re hosting your own WordPress install, you’ll soon have access via the Extend theme directory. And of course the new theme will be bundled with WordPress 3.5 due later this year.
This year’s theme was designed by former NFL playerDrew Strojny, though as with all things WordPress there was plenty of help from the WordPress community. The WordPress blog has more details about Twenty Twelve and there’s a live demo you can check out as well.
That's a lot of screens, are your images ready? (testing using Adobe Shadow). Photo: Adobe.
No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants their images to look good on the multitude of screens connecting to today’s web. Finding the balance between the myriad factors — screen resolution, screen size, bandwidth, layout and design — is a tricky process.
You’re probably familiar with breakpoints in responsive design, they’re the screen widths in your media queries. For responsive images the idea is the same; a “breakpoint” is the screen size at which you swap in and out different size images.
At first glance it might seem logical to use the same breakpoints for your images that you’re using in your CSS media queries, but as Cloud Four’s Jason Grigsby writes, that’s not always the ideal solution. Grigsby tackles the potentially tangled question of breakpoints in a new post, So How do You Pick Responsive Images Breakpoints?
To simplify what can be a very complex question, Grigsby ignores some scenarios, including the so-called “art direction” use case where images are optimized (cropped differently, for example) for different screens. Instead Grigsby focuses on the question of how to best select “different image files with different resolutions of the same image based on the screen size.”
The simplest solution is to just make your image and responsive design breakpoints the same, but that’s rarely going to be ideal for your site’s visitors. Here’s what Grigsby has to say about using the same breakpoints for both image and media queries:
If we were talking about the art direction use case, then it is likely that the breakpoints would be the same because changes in the layout might also indicate an edit to the image.
But in the case where we’re simply changing files to provide different resolutions and a faster download, the image breakpoints should be determined based on when the browser is downloading an unnecessarily large file.
The main problem is, what constitutes an “unnecessarily large file”? But even if you answer that, as Grigsby writes, you still haven’t answered every question:
How do you determine what is an unnecessarily large file? Is that 1 byte? 10k? 20k?
And if you can answer that question, how do you determine the resolutions at which those file size jumps are going to occur? Depending on the content of an image and the compression algorithm used, images are likely to have different resolutions at which they experience significant changes in file size.
In the end Grigsby doesn’t yet have an answer to the question of how to handle responsive image breakpoints. And neither do I. There just isn’t an easy answer that will work for every project. My thinking, and what I’ve done on my own site, runs pretty much along the same lines of Eric Portis’s comment on Grigsby’s post. If you’ve got ideas, head over to Cloud Four and let them know how you’re doing it.
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.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code