It seems incredibly antiquated to mention this technique, when there are better researched ones available.

- There is matchmedia that has been mentioned by James Wragg.

- clientWidth is not always accurate as James Pearce has found out

- Jon Neal has done some exhaustive research with several others to find out what mobile devices actually use

This topic is so incredibly important for web developers to pay attention to.

Where I run into some confusion is identifying the fine-line-difference between responsive and scalable. Responsive implies that there are needs (inferred or gathered) to be addressed. We all know that a user viewing our sites on mobile devices have needs that are different than those on desktop screens. Responsive design goes a long way to begin addressing those needs. But what happens when I simply resize my browser window? Do my needs change? Or does everything just need to scale?

Responsiveness and scalability appear to be closely related, yet remain distinctly different. The former aims to solve needs, while the latter ushers/facilitates a design to the point until the user’s needs change.

I think there should be a beginning design (mobile) and ending design (large screen) put together in the early stages which can then be used as the boilerplate constraint (so to speak) for whatever then needs to come in between. This way, you can account for what elements need to come in and go out.

From a building point, yes I probably agree, mobile first.

I think this is great, I did something recently when loading in twitter follower avatars. Paul Hayes recently wrote an article (http://www.paulrhayes.com/2011-11/use-css-transitions-to-link-media-queries-and-javascript/) about triggering JavaScript based on events fired from CSS properties. It’s still not a perfect solution, but I think it will help with these sorts of problems.

Being able to trigger JavaScript events based on media queries allows us to be sure that if the page triggered a smaller media query when it loaded and then the browser was resized, that the additional content gets loaded in. Jeremy’s if statement works great on page load, but won’t load the content if the page size changes.

I was talking about this technique at a workshop recently and Andreas Nebiker pointed out that it feels a little wrong having to specify the breakpoint (640 pixels in this case) in two different places: the CSS and the JavaScript. He pointed out that you could instead test for some updated CSS value in the JavaScript.

I’ve written some more about it on my blog if you’d like to know more. Basically it means you only have to specify your breakpoint once: in the CSS.

IDA: I think that if we look at the business implications of design techniques such as the one in this post, it is undeniable that the needs of mobile users are VERY different than those of a user on a desktop screen. And it is not necessarily a need rooted in speed all of the time. Of course the needs of users on different screen sizes do converge at points, but the underlying needs are different.
I think Jeremy inadvertently touches on this in the example. Was Jeremy displaying the the results of a google search on a larger screen size simply because he had the screen real estate to do so? I don’t think so. I think that there is an underlying assumption about user intention as screen sizes change.
If a user is on a tiny screen and is mobile, every business behind a website needs to ask why would someone sitting on a train look us up on their phone? What would they be looking for?
I believe that it is short-sighted of us as web developers to assume that the needs of those on smart phones are the same as those on a desktop. At the end of the day, this becomes less about actual screen size and more about user behavior and how we respond to it in our designs.

I have the same query as Paul (Boag). It’s not the focus of the article and I know it’s the concept rather than the implementation but…

‘It’s taking progressive enhancement to the next level’

This is a technique that’s dependant on JS, so is JS not a consideration for progressive enhancement now? With JS turned off a desktop user gets a sidebar with a link away from the site. Is this an OK trade-off? I guess it depends on the content but it’s getting harder to build dynamic sites that don’t rely on JS.

Already applying this for my projects, nice to know that more people will manage the content this way.

Thanks for writing this anyway !

Merry Christmas Jeremy.

The technique you described on your blog to test for a specific CSS property to avoid specifying your breakpoint more than once still violates the DRY principle. For example if you decide the sidebar is no longer to be floated right you still have to change both your CSS and Javascript.

Do you have any ideas how to avoid this, Oh Wise One?

Can I quibble just a teeny bit with the use of “bloated” to describe the desktop version of a site? Perhaps I’m being over-sensitive, but to me it suggests that Mobile-First isn’t so much a design strategy, intended to make it easier to properly accommodate the wide range of modern browsing devices, but is instead an attitude towards those devices. It hints that the desktop site is really just the mobile site with a bunch of extra crap sludged on top.

Be careful with this technique: it can lead to big problems in terms of SEO because even if Google indexes and load AJAX, the easiest way is still to have much of the displayed content in this original HTML file.

But the example is obviously a very good solution and you can even extend it to widgets like Facebook, Twitter and others that may be useful on the desktop version but unnecessary for the mobile version.

Thought you might want to see a similar strategy that Wikipedia uses:

video

slides: http://wikitech.wikimedia.org/view/File:OSCON_2011_-_ResourceLoader_-_Trevor_and_Roan_(with_notes).pdf (sorry, Textile doesn’t work because of the parentheses in the URI)

Divya, I’m sorry to hear that you think this technique is antiquated but I think you may be focusing on the specifics of the width detection rather than the idea.

As I said, I’ve posted some follow-on ideas on my blog about detecting CSS changes rather than directly measuring viewport width with clientWidth.

But in any case, I hope you can see beyond the specifics of my unworthy antiquated if statement and recognise that it is the thinking behind conditional loading that is important rather than the code itself.

@Paul Boag
Sure, it starts with the cat news. God knows where it could end up.

Thanks! This was amazing, and a great starting point for someone interested in learning responsive design. <3 you.

I’m trying to do a mobile first design and thought conditionally loading Google DFP ad tags depending on size would be a good idea. Can’t seem to get the JavaScript to be executed once it’s loaded into the document.

I’m completely new to DOM manipulation but I think what I need to do is causing me pain because you have to insert new HTML and JavaScript into the document because the ad call is dependent on a like-named id. See here: http://stackoverflow.com/questions/8610574/inserting-and-executing-conditional-javascript

Any advice would be greatly appreciated.

This definitely seems like the simplest approach to managing assets/elements for various viewports.

Thanks for writing this, Jeremy!

Great example of how this can be used, and a good mindset to get in to focussing on the content first.

Glad I read this before I tackle the next responsive site.

Jeremy – thanks for leading the way. Concise and brilliant synthesis of responsive web design, progressive enhancement and the mobile/content first approach. What an exciting time this is to be a web developer.

In this mindset you expect that mobile will be more important then desktop in the future?
I like the idea because if you think of it, it is much simpler to start with the basics for mobile and than upgrading it for desktop. Starting with a desktop design and than stripping it to a mobile version can give much more problems.

This is a really simple but great solution for designing responsive sites in the UK where mobile web speeds aren’t great.

“In this mindset you expect that mobile will be more important then desktop in the future?” – Kurt

Why the either/or? It this point, I am changing my strategy to be more “device” focused instead of mobile or desktop. Same process though. Which makes loading of assets (may it be content or scripts) even more important in terms of performance/speed (i.e. do you really need that much for this situation?)

The view condition on which this code runs is undoubtedly simple & good for this example, but anything more complicated and it may be more useful to use window.matchMedia which allows you to test @media rules (inc. pixel-ratio, orientation etc.) from your Javascript.

A polyfill is also available in matchMedia.js.

I wanted functionality like this, but I wanted to be able to use PHP to actually display different content on the initial page load, so I hacked together Simple RESS (inspired by Lukew’s article imagining RESS).

It doesn’t benefit from the delayed page load, but it might be something to pair together with this technique to responsively adjust content.

The issue is that the technique will not work with a browser you are resizing manually. I’m not sure what is the proper solution though.

It’s worth binding size-queries to the document’s load event (or even, in some cases, to a point some time after that).

On Android v2.3 for body.clientWidth, for example, (and other platforms, if there are different measurements you’re querying), these values can change radically during the page’s lifecycle.

There’s data here

I guess the only problem with this is it is reliant on JS. If there is no JS then there is no cat news. Should we care about this? I guess its only secondary content so isn’t the end of the world.

Great article, but am I missing something?:

<blockquote>Visitors with small-screen devices will see that link to the search results; visitors with larger screens will get the search results directly.</blockquote>

When I view the “See the result” page, it’s the same on my iPhone as it is on my desktop. The sidebar is always visible. I don’t see any link to the search results.

That page should be a working demo, right?

I really think this is a simple and effective solution to manage side content for various screen sizes. Thank you.

It seems to me that a good solution [for those worrying about lost content] would be to load the additional content once the user scrolls down to it, seeing as in this specific example (and in most mobile designs) the floats just end up beneath the main content. Having said this, as a user I really hate seeing my page lengthen just when the end is in sight; a button may be a less violent approach.

On a less logistical note, the question is ‘who needs to see this aside’ (1) vs. ‘who wants to see this aside’ (2). The first may be possible to deduce from the content of your website, but I’m not sure (2) can be (as I assume has been done here) implied from the device: I cry every time youtube gives me only super-LQ videos when I browse it with a Nokia.

Jeremy, I would be happy if this article was used to explore techniques that are being resolved right now by various developers around this. As you know very well, this is not an area where there is a simple, defined answer yet. But the thrust of the article suggests there is an easy one, especially one that will not work most of the time outside of a desktop browser.

Divya – perhaps you should write an article like that yourself.

You’ve posted some links to other’s work on this subject, which is helpful. Thanks.

As with all web techniques, there’s things that can be improved and more to learn as our understanding grows. The entire scope of that work could not effectively be summed up in one article without leaving the reader bamboozled. The purpose of this article was to introduce the technique, and it does so very helpfully.

@Matt

I think that there is an underlying assumption about user intention as screen sizes change.

The problematic assumption for me is the one that assumes phone users are always “on the go”. You mentioned the train in your comment, which is the most common and cliched example I hear. I browse the web an awful lot on my phone, but more than half the time I am sitting still and want the same things I’d want if I were at my computer. Moreover, even when I’m “on the go”, I still want those same things. Businesses that think their desktop and mobile users have totally separate needs should go away and think about what the purpose of their website actually is.

Great article Jeremy. Only thing I’d add would be to hijax the link to trigger searchNews when clicked rather than taking you off-page. But like you said, it’s more the idea than the code.

David Goss wrote: “Only thing I’d add would be to hijax the link to trigger searchNews when clicked rather than taking you off-page.”

Excellent idea! You’d still only need to write the Ajax code once, but you’d simply change the event that triggers it based on viewport size:

On a large viewport, trigger the Ajax request once the page has loaded.

On a smaller viewport, trigger the Ajax request when the link is clicked.

I like it!

Divya and the Jameses Pearce and Wragg have already provided some useful links to research and techniques for measuring layout. Thank you muchly. Here’s another handy related resource:

Scott Jehl has written some conditional-loading code for a similar situation, which he calls the anchor-include pattern. It progressively enhances links to fragment identifiers in other documents so that the contents of that fragment is requested once the page has loaded and inserted into the DOM (either before the link, after the link, or replacing the link).

You could take that code and wrap it in a test for screen width—be it using the humble but flawed clientWidth, the more powerful matchMedia, or by testing for a specific CSS property. In fact, Scott has updated the code so that you can supply an optional threshold property to specify a pixel value that the screen needs to be above in order to trigger the Ajax request.

It’s written in jQuery but I don’t think it would take too much rewriting to make it work without that dependency (although jQuery does make the Ajax part a lot easier).

Tried to improve your JS by making it more modular, cleaner and inline with current best practices: https://gist.github.com/1430996

Elliot, I don’t see JS a requirement. All of the content is always available: sometimes it requires an extra click (small screen or non-JS) and sometimes it is provided after page load (large screen with JS enabled) but crucially, the content is always accessible.

Also, the content of the page does not require JavaScript; it is delivered in HTML. The extra stuff (delivered in the sidebar) is not the main content of the page. In fact, the real question shouldn’t be “can I deliver this content to users of any device?” but rather “should I be delivering this content to anyone?”

A good way of thinking about what constitutes the content of a page (as opposed to nice-to-have additional stuff) is to consider what information would be delivered in an alternate representation. For example, if this were a JSON or XML file, what content would be represented?

I’ve been doing a lot of responsive development lately, but I’m still doing the “desktop down” approach versus the mobile first. I’ve had problems trying to wrap my brain around that approach as it requires a lot of additional thinking. Not sure if mobile first is the future or not of front-end development, but I need to experiment more :)

Clayton: Yikes! I’m not quite sure what happened there. I somehow managed to over-write an entire blog post. It may be down to the fact that I’m a complete idiot.

Well, I’ve managed to recreate it from memory so it’s back online.

Thanks for the heads-up. Sorry about the confusion.