Responsive images are a difficult beast to tame: there really isn’t a good solution for them today. As a result, some discussion started on the WHATWG mailing list months ago about what to do. The WHATWG pointed out that the list was for standardizing and suggested it would be better if the discussion were moved into a community group.

So, obediently, a community group chaired by Mat Marquis was started (in February). A lot of discussion took place about the appropriate way to handle responsive images and one solution, the new picture element, garnered the majority of support.

On May 10th, the previously mentioned srcset attribute was presented on the WHATWG mailing list by someone from Apple.

That same day it was recommended to the list that they take a look at all the discussion that had taken place in the community group. A debate about the two solutions ensued.

The feedback from developers was not particularly glowing. To quote Matt Wilcox:

I do not see much potential for srcset. The result of asking the author community was overwhelmingly negative, indirection or no indirection.

It was argued by Simon Pieters of Opera that the srcset attribute would be easier to implement and that as a result, that would help developers:

I think an attribute is simpler to implement and thus likely to result in fewer bugs in browsers, which in turn benefits Web developers.

This morning, the attribute was added to the spec.

I’ve got my own opinion about the correct solution, but that’s not really what’s I think is most troubling here. Note what happened:

1. Developers got involved in trying to standardize a solution to a common and important problem.
2. The WHATWG told them to move the discussion to a community group.
3. The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element.
4. Another (partial) solution was proposed directly on the WHATWG list by an Apple employee.
5. A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute.
6. While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft.

What. The. Hell.

The developer community did everything asked of them. They followed procedure, they thoroughly discussed the options available. They were careful enough to consider what to do for browsers that wouldn’t support the element—a working polyfill is readily available. Their solution even emulates the existing standardized audio and video elements.

Meanwhile an Apple representative writes one email about a new attribute that only partially solves the problem and the 5 days later it’s in the spec. In case there is any doubt, I’m not blaming him at all for how this all played out. That blame falls on the WHATWG. Whatever their rationale was for putting this in the draft, the method in which it was added reeks of valuing the opinion of implementors over developers.

In the draft of the W3C HTML design principles, they clearly state the priority that should be given when determining standards:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.

Those levels of priority make a lot of sense to me and it’s discouraging (to say the least!) to see them dismissed in this case. This kind of thing simply cannot happen. It’s tough to get people to voice their opinions to begin with. To find that their opinion holds no weight won’t make it any easier going forward.

What message does it send when developers try to contribute their time, energy and effort to help solve a problem only to have it so casually dismissed?

As Scott Jehl responded on Twitter:

insulting. Not to mention, that it can’t work today. What was the purpose of our @w3c community group?

Insulting indeed. Not too surprising though. After all, we’ve seen this sort of thing before.

The lineup is amazing. Seriously.

Dave Rupert, lead developer at Paravel, co-host of the ShopTalk podcast, and creator of awesome tools like FitVids and FitText, will get the day kicked off with a four hour workshop.

After lunch, Mat Marquis will get the afternoon started with his presentation, “Next Steps for Responsive Design”. Mat worked on the Boston Globe project and heads up the Responsive Images Community Group for the W3C, so he’s got some hard-earned experience to pull from. He’s also a seriously funny guy.

Then, Kristofer Layon will present “The Minimal Viable Web”. Kristofer is the author of two books, most recently the excellent “Mobilizing Web Sites”. I love how practical and pragmatic that book is and I expect his talk will keep the same tone.

I’ll close the day with a new talk for me, “Creating Responsive Experiences”. I’ve been on a kick for awhile now that I think responsive design has to be about more than just layout, and I’ll try to make my case (and back it up with a few examples).

It should be an awesome day! The venue, Open Book, has a cool feel to it and we’re going to keep attendance low—you won’t be lost in a huge ballroom of people.

There are still passes available. If you want to make the trip (and you do!), code ‘KADLEMN’ will shave $100 off the cost of registration.

I hope to see you in Minneapolis—it’s going to be awesome!

First, any credit has to go to the awesome team at Cloud Four. Most of the tests were created by them for some testing they were doing. I just added some Javascript to automate them.

On to the results!

Test One: Image Tag

Run the test

This page tried to hide an image contained within a div by using display: none. The HTML and CSS are below:

<div id="test1">
    <img src="images/test1.png" alt="" />
</div>

@media all and (max-width: 600px) {
    #test1 { display:none; }
}

The results

If there is one method of hiding images that I can say with 100% certainty should be avoided, it’s using display:none. It’s completely useless. It appears that Opera Mobile and Opera Mini don’t download the image (see the initial post for the reasons why), but the image is requested by, well, everyone else.

Conclusion

Simple: don’t do this.

Test Two: Background Image Display None

Run the test

In this test, a div was given a background image. If the screen was under 600px wide, the div was set to display:none. The HTML and CSS are below:

<;div id="test2">;<;/div>;

#test2 {
    background-image:url('images/test2.png');
    width:200px;
    height:75px;
}
@media all and (max-width: 600px) {
    #test2 {display:none;}
}

The results

The same as with the first test: every browser tested, aside from Opera Mini and Opera Mobile, will download the image.

Conclusion

Once again: don’t do this. Thankfully, as some of the other tests show, there are a few easy ways to hide background images without having the image requested.

Test Three: Background Image, Parent Object Set to Display None

Run the test

In this test, a div was given a background image. The parent of the div (another div) was set to display:none when the screen was under 600px wide. The HTML and CSS are below:

<;div id="test3">;
    <;div>;<;/div>;
<;/div>;

#test3 div {
    background-image:url('images/test3.png');
    width:200px;
    height:75px;
}
@media all and (max-width: 600px) {
    #test3 {
        display:none;
    }
}

The results

Kudos to Jason Grigsby for catching this one. On the surface, it’s not entirely obvious why this would be any different than test two. However, when doing his initial research, he noticed this seemed to make a difference so he decided to test it. Lucky for us he did because this method is actually pretty reliable.

Conclusion

This method works well. With the exception of the over-eager Fennec, every tested browser only downloads the image when needed. The issue with this method is that you do have the requirement of being able to hide the containing element. If that’s an option, then feel free to go ahead and use this approach.

Test Four: Background Image with Cascade Override

Run the test

In this test, a div is given a background image. If the screen is under 600px, then the div is given a different background image. This tested to see if both images were requested, or only the one needed. The HTML and CSS are below:

<;div id="test4">;<;/div>;

#test4 {
    background-image:url('images/test4-desktop.png');
    width:200px;
    height:75px;
}
@media all and (max-width: 600px) {
    #test4 {
        background-image:url('images/test4-mobile.png');
    }
}

The results

While certainly better than using display:none, this method is a little spotty.

Conclusion

I’d avoid it. While the situation is improving, Android 2.x, which dominates the Android marketshare, still downloads both images as does Fennec and the Kindle. Between the three, but particularly because of Android, I would recommend looking at other options.

Test Five: Background Image Where Desktop Image Set with Min-Width

Run the test

In this test, a div is given one background image if the (min-width: 601px) media query matches, and a different one if (max-width: 600px) matches. The HTML and CSS is below:

<;div id="test5">;<;/div>;

@media all and (min-width: 601px) {
    #test5 {
        background-image:url('images/test5-desktop.png');
        width:200px;
        height:75px;
    }
}
@media all and (max-width: 600px) {
    #test5 {
        background-image:url('images/test5-mobile.png');
        width:200px;
        height:75px;
    }
}

The results

The situation here is a little better.

Conclusion

More browsers play along this time. Fennec, as always, just can’t control itself. Android 2.x is….odd. It requests both images, but only if the screen size is over 600px and the min-width media query kicks in. This behavior appears to stop as of Android 3. This is an odd one and I would love to know why the heck it happens. Actually, good news here. Jason Grigsby pinged me and said his results for this test weren’t jiving with what I reported here, so I re-ran the tests on a few Android 2.x devices. Turns out, my initial results were off: Android 2.x plays nicely and my initial runs of this test on that platform were wrong. Not only is this good news for developers, but it is also a much more sane behavior and it has restored my faith in humanity. Or at least my faith in Android.

It’s also worth nothing that if you use this method, you’ll need to consider alternate options for Internet Explorer 8 and under. Those versions of the browser don’t support media queries, so no image will be applied. Of course, this is simple enough to fix with conditional comments and an IE specific stylesheet.

Test Six: Background Image Display None (max-device-width)

Run the test

This test was the same as test two, but it used max-device-width for the media query instead of max-width. The HTML and CSS is below:

<;div id="test6">;<;/div>;

#test6 {
    background-image:url('images/test6.png');
    width:200px;
    height:75px;
}
@media all and (max-device-width: 600px) {
    #test6 {
        display:none;
    }
}

Conclusion

I’m not going to spend much time on this, as it ended up being a throw away test. There were no differences in behavior between this and test two. The test was added because of a tweet where someone had mentioned they were getting different results than the original tests by Cloud Four, but the discrepancy ended up being caused by something else entirely (a typo, if I remember right).

Test Seven: Cascade Override for High Resolution

Run the test

The final test was added to the suite a bit late. With the retina iPad around the corner, there were a lot of posts about how to handle serving images to high-res displays. In one post, Brad Frost mentioned he thought it would be interesting to see test results for this, so I added it in.

In this test, a div is given a background image. Then, by using the min-device-pixel-ratio meda query, a new background image was applied if the minimum ratio was 1.5.

The HTML and CSS are below:

<;div id="test7">;<;/div>;

#test7 {
    background-image:url('images/test7-lowres.png');
    width:200px;
    height:75px;
}
@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (min--moz-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min-device-pixel-ratio: 1.5) {
    #test7 {
        background-image:url('images/test7-highres.png');
        width:200px;
        height:75px;
    }
}

The results

Of all the tests, this one is the one that could benefit the most from having some more people run it. That being said, it does look like the following behavior is accurate.

Conclusion

Again, this test could stand to be run a bit more, just to be safe. It looks like this method will work the vast majority of the time. Unfortunately, it appears Android 2.x will download both images if the device pixel ratio is above or equal to 1.5 (or whatever value you set in the media query). So in the case of the above tests, if you’ve got a high resolution device running Android 2.x you’re out of luck.

The good news, for now, is that I’m unaware of any Android device with a device pixel ratio over 1.5. So if you’re targeting the retina display iOS devices, you could set your min-device-pixel-ratio to 2 and be safe. And of course, now that I’ve said it, I fully expect the first 3 comments for this post to all correct me and point out the one Android device that just has to prove me wrong.

The earliest rounds of this test looked more promising for Android, so this is a bit of a bummer for me. They’re the only browser that seems to mess it up, but they’re also one of the biggest players.

Recommendations

If you’re going to hide a content image, you’re not going to be able to do it by setting display:none. I recommend using a Javascript or server-side based approach instead.

If you want to hide a background image, your best bet is to hide the parent element. If you can’t do that, then use a cascade override (like test five above) and set the background-image to none when you want it hidden.

For swapping background images, define them both inside of media queries.

Going Forward

If you run any of the tests and think something above is incorrect, either drop me a line or say report it on GitHub so I can dig into it. The same goes for adding any additional tests.

Mark Boulton just put his thoughts to screen with a post entitled “Responsive Summit: The One Tool”. In it, he makes the case that knowing your materials is more important than using a specific tool. He makes an excellent point when he discusses why he feels comfortable in Photoshop:

Since 1997, I’ve been working almost exclusively on the web. Throughout all of that time, the realisation of what the projects would look like are done in Photoshop. That means, yes, I’ve been using Photoshop in a production environment for fifteen years. Malcolm Gladwell said it takes 10,000 hours, or 10 years of repetitive use, to become an expert in something. I guess that means I’m an expert in creating pictures of websites. Photoshop is like an extension of my mind. To use Photoshop for me is as effortless and almost as fast as a pencil. I get stuff done; quickly.

That point, that the familiarity you have with a tool matters, is an important one to keep in mind. Designing is a creative endeavour. You can’t do it well with tools you aren’t entirely comfortable with.

If we had been designing in the browser since 1997, this would all be a non-issue. Of course it wasn’t possible back then to do so—our tools were too limited. That’s not the point I’m making. The point is that if we had that same level of experience designing in the browser, I suspect no one would debate whether the approach made sense. Designing in the browser lets you get deeply entrenched in the characteristics of the web. Designing in a graphics editor like Photoshop removes you from them.

Those against designing in the browser talk about how working in code is too limiting. Of course the opposite is true as well—working in a graphics editor is too limiting in many ways. You are limited to designing for a specific size at a time. You are limited by not being able to design for interactions. That’s a big one. The web is an interactive medium, not a static one. It has little in common with print and much more in common with software. Graphic editors, for all their powerful tools, aren’t equipped to handle this.

There is room for a better tool here. One that lets you experiment easily, but doesn’t detach you from the constraints and capabilities of the environment you are creating for. Later in his post, Mark continues:

I can’t have happy accidents in a browser when I’m writing specific rules and then watching the results in a browser. There is too much in the feedback loop.

This made me think of a presentation by Bret Victor called “Inventing on Principle”. Not only do I recommend it, I think it should be required viewing.

During the presentation he discusses the need for immediate feedback from our tools:

Creators need an immediate connection to what they create. And what I mean by that is when you’re making something, if you make a change or you make a decision, you need to see the effect of that immediately. There can’t be any delay, and there can’t be anything hidden. Creators have to be able to see what they’re doing.

Specifically, he tackles coding. He demonstrates a tool that lets him instantly see how the changes in his Javascript affect the canvas for which he is creating. This instantaneous feedback provides fertile ground for experimentation, and he demonstrates that over and over in the video. Because of the direct connection between the code and the result, you’re able to start using advanced controls (start around 3:45 into the video, and again around 10:45) to help the process of discovery and experimentation.

This, I think, is where we need to head. We need to be able to create on the web, but we need tools that make it easier for us to experiment. Tools that let us be creative without decoupling us from the very medium we are creating for.

We’re not likely to ever remove a graphic editor completely from our workflow, nor should that be our goal. There is nothing wrong with graphic editors. We simply need to be aware of what they are good at, and where they fall short. Instead, our goal should be to move towards tools and processes that let us capitalize on the interactive nature of the web.

It’s about using the right tool for the right job. I’m not convinced we have the right tool yet.

To that end, I’ve hacked together a few tests (using Jason’s tests as a starting point) that store their results in Browsercope. The test is fairly simple. For each test case, I check to see if the background image (or content image) has been loaded by checking the image.complete property. The property (which appears to be well supported) returns true if the image has been  requested and downloaded, and false otherwise. So, if I want to see if image2.png has been downloaded, my code looks like this:

var myImage = new Image();
myImage.src = ‘http://somedomain.com/image2.png’;

if (myImage.complete) {
 //already downloaded
} else {
 //not yet downloaded
}

Early results

It’s early, but already a few trends (some interesting, some less so) are emerging:

• Setting an image to display:none won’t stop the image from downloading (see test 1). So don’t do it. We already knew this, but the tests are reinforcing it.
• The same goes for setting an element to display:none: the background will still be downloaded by everybody (see test2).
• Setting the parent object to display:none, however, does work pretty consistently (see test 3). It looks like Fennec still downloads the image, but Android, iOS and Opera won’t.
• Downloading behavior for a simple cascade override is pretty inconsistent (see test 4). However, setting background images within a media query and then overriding seems to work pretty well (test 5). Fennec is a little eager again, but Android, iOS, Opera and the Kindle only download what’s needed.

Finally, my favorite nugget of information so far pertains to Opera Mobile. Opera, as it turns out, is darn clever. Instead of using the parser to trigger resource downloading, they use layout code. This means that since they have information about viewport size and visibility settings, they can be much more selective about which resources they download. So, for example, if an element is outside the viewport then the background image doesn’t have to be downloaded on page load.

When I talked to Ola Kleiven of Opera about this optimization, he said that Opera used to implement the same behavior on Opera for desktop prior to 11.60 but had to pull it due to compatibility reasons. Developers were relying on things like the load events of these images, so when they didn’t load in Opera, things would break. It’s too bad: it’s an interesting and effective optimization method. I would love to see this behavior implemented cross-browser, but as an opt-in feature (maybe a meta tag or something could trigger it).

Thanks to everyone who has already been testing—it’s been fun to watch the results come in! If you haven’t run the tests yet and you’ve got a few minutes, please do. Once the number of results gets to a nice level, I’ll post a more detailed follow-up about which browsers behave in what ways. I’ll also include any interesting findings in the book.

In the meantime, feel free to fire up the tests on any and all devices you have. If you think of another test you would like to see added, or see a potential issue with the test, let me know. One of the benefits of automating the test results is that it should be very easy to add new tests and quickly get broad results.

We’ve responded by creating a lot of tools that help us collect this information. We can easily store quotes, snippets or even full articles in any one of a hundred different sites and services. We can save links to the videos and recordings that moved us on some level. RSS feeds make it incredibly easy to consume massive quantities of online articles and blog posts. Tools like the incredible Ifttt help make our many online services interact with each other, further easing the process of collecting information.

But what happens to that information after it has been carefully tagged and stored away? The more new information we collect, the more old information gets buried. That post we read that sparked an idea, that quote that stirred something deep within—lost and buried. Forgotten amongst the piles of all the other information we’ve collected.

Certainly this is nothing new—the issue has merely been amplified. Technology, though, is supposed to work for us. It’s supposed to help us solve issues we’ve had in the past. Why not push our tools to not merely collect, but to remind us what is already there?

We need more services like the Kindle Daily Review and Timehop. Kindle’s Daily Review delivers “flash-cards” of a book you’ve read in the past. It displays notes and highlights that you made. It’s fantastic! I love seeing a passage from a book that I had forgotten all about, but that still sparks something within me. Timehop is similar—it lets you know what you posted on Twitter, Facebook, Foursquare or Instagram a year ago. I’ve only been using that service for a short time, but already I’ve found several articles and conversations that I had forgotten about.

Why is this important? Because serendipity is a stimulant. In his book, “Marshall McLuhan: You Know Nothing of My Work”, Douglas Coupland had this to say about Marshall McLuhan, one of the most prescient minds of the last century: “For Marshall, the fun of ideas lay in crashing them together to see what emerged from the collision.” When you rub two stones together, you can make a spark that starts a fire. Put two seemingly unrelated ideas next to each other and the effect is the same.

Searching, for the most part, eliminates those kinds of serendipitous discoveries. It’s a more or less direct path to the very specific type of information we are looking for. A service like the Kindle Daily Review, a service that provides automated nostalgia—that’s the kind of tool that encourages the mixing of ideas, the friction that causes the spark.

We have enough piles. What we need are more shovels.

And of course, it’s responsive. That adds another level of loveliness. The navigation adjustments in particular are kind of interesting to watch. My favorite layout is the last one to kick in before you hit 1020px. It’s clean, easy to read, and the ads are not yet there.

But….

There’s a catch here. For as lovely as the site looks, there’s a lot going wrong from a technical perspective.

Performance

For starters, the size. Even on my phone, the site weighs in at a massive 1.4MB. A large part of the issue is that those ads, the same ones that don’t display below 1020px, are still being requested and loaded on smaller resolutions. They’re just being hidden with a little touch of ‘display:none’.

When I tested, the site also made about 90 requests. That’s an awful big drag on page load time—no matter what device or network you are viewing the site on.

Advertising

Another potential concern is the advertising. I’m not sure exactly on Smashing Magazine’s business model, prices, etc., so it’s hard to criticize their advertising efforts too much. I do find it interesting that their ads are all hidden below 1020px though, leaving their ads visible to only a portion of their audience.

One reason for this may be the high number of ads they display. In their sidebar, I count 16 ads. They are distracting at large resolutions, so I imagine they got to be very overwhelming on smaller resolutions. Having to re-orchestrate 16 ads onto a small screen layout would be a very tall task.

Again, we’re talking business model here so there’s obviously much more at play than what an outside perspective grants, but I would love to see fewer ads. Not just for Smashing Magazine, but across all sites. Less ad spaces, more money per slot. (Roger Black talks about this in detail in his posts The holy grail, part 1 and part 2.) The result would be three key improvements:

1. You would have a lighter, cleaner experience.
2. The ads would provide more value to the advertisers—less ads competing for eyeballs per page.
3. The smaller number of ads would be much easier to manage across resolutions.

Bigger picture

Now, having said all that, I could be guilty of premature condemnation. Perhaps this is the interim solution and a fix to these issues (performance in particular) is forthcoming.

Jason Grigsby put it nicely in two tweets:

When I have guests and don’t have time to clean, I shove things in a closet. No biggee. Everyone does it. But the house isn’t really clean.

The key is following through and cleaning the closet as well. Let’s hope others are better at it than I am at home. :-)

Of course he’s right. In fact, I have a few messy closets myself. (Both literally and metaphorically.)

And I don’t mean to pick on Smashing Magazine. They are far from the only site making these kinds of mistakes on the technical side of things and from a business perspective, the discussion about how to handle advertising is far from being resolved. And again, from a visual perspective I think they did an awful lot of things right.

We simply need to ensure that the discussion broadens. Responsive design is a fantastic approach, one that brings us closer to taking advantage of the inherent flexibility of the web. But simply being responsive is not the destination. To maximize the potential of a responsive approach, we need to focus not only on the visual components, but on the technical execution and business ramifications as well.

To say I’m excited is a bit of an understatement. I love sharing what I know, and writing a book has been something I’ve wanted to do for a long time. I’m not sure of the exact publication date yet, but it looks like the book should be out sometime in the second half of the year.

Uh…there’s already an awesome book on responsive web design

Why yes, there is, and I wholeheartedly recommend buying a copy. Like, now. Ethan’s book is a brilliant read. I even wrote a glowing review shortly after finishing it. In that review, I said I was pining for a sequel—something that would build on the core principles Ethan discussed. When Michael Nolan of New Riders got in touch a few months ago and asked if I was interested in writing a book, I saw it as an opportunity to get that book written.

More info, please!

The book will be an exploration of how a responsive approach can be integrated into the workflow—from planning and early mockups through to the actual development of the site. In addition to fluid layouts, media queries and fluid images, the book will discuss topics such as design deliverables, structured content, feature detection and server-side enhancements.

If you want to keep up with the progress, your best bets are to follow me on twitter, stay tuned to this blog, and sign up for the mailing list at responsiveenhancement.com.

I’ll keep you posted!

One interesting trend—at least to me—is that I returned to reading a lot more web related books (10!) this year. This is in no small part related to the A Book Apart series. If they keep churning out quality books like this, that count is likely to stay very high.

As always, if the book made this list, then I enjoyed it on some level. There are far too many good books out there to suffer through one that doesn’t interest me. If I’m not enjoying it I set it aside.

If you’re looking for specific recommendations, “The Invisible Man” (which I had read before and will read again) and “The Demolished Man” top my (short) list of fiction. “Obliquity”, “Marshall McLuhan: You Know Nothing of My Work!” and “The Death and Life of the Great American School System” are at the top for non-fiction (excluding the web-related ones).

1. Hardboiled Web Design by Andy Clarke
2. 2001: A Space Odyssey by Arthur C. Clarke
3. Linchpin by Seth Godin
4. Pull by David Siegel
5. The Death and Life of the Great American School System by Diane Ravitch
6. Confessions of a Public Speaker by Scott Berkun
7. Rainbows End by Vernor Vinge
8. The Demolished Man by Alfred Bester
9. Where Good Ideas Come From by Steven Johnson
10. HTML5 for Web Designers by Jeremy Keith
11. Obliquity by John Kay
12. Responsive Web Design by Ethan Marcotte (See my review)
13. Adaptive Web Design by Aaron Gustafson
14. CSS3 for Web Designers by Dan Cederholm
15. The Elements of Content Strategy by Erin Kissane
16. Presentation Zen by Garr Reynolds
17. The Invisible Man by HG Wells
18. The Filter Bubble by Eli Parson
19. Big Deal by Robert Hoekman Jr.
20. Delivering Happiness by Tony Hsieh
21. The Information by James Gleick
22. Mobile First by Luke Wroblewski (See my review)
23. Designing for Emotion by Aaron Walter
24. Content Strategy for the Web by Kristina Halverson
25. Bird by Bird by Anne Lamott
26. Marshall McLuhan: You Know Nothing of My Work! by Douglas Coupland
27. Mindfire by Scott Berkun
28. Simple and Usable by Giles Colborne
29. Loose by Martin Thomas

This year’s post is an overview of how inconsistent mobile networks are, as well as a plea for more communication between carriers, manufacturers and developers. If you’re interested in mobile performance, please give it a read.

Be sure to check out the rest of the articles there as well. As usual, there’s lots of good content already posted with more sure to come. In particular, I recommend Stoyan’s post on asynchronous snippets, Guy’s look at when you should and shouldn’t inline resources, and a post on localStorage performance by Nicholas.