Using Media Queries in the Real World

Warning This article was written over six months ago, and may contain outdated information.

Recent­ly I’ve been work­ing on the new web­site for my employ­ers, Poke Lon­don, which launched last week. One of the things of which I’m proud­est is the use of media queries to cre­ate a site which is sym­pa­thet­ic to small-screen devices. I learned a lot from devel­op­ing with media queries, not least of which was the lim­it of what’s pos­si­ble with them, so I thought it would be use­ful to present some of the key lessons learned in this post.

By the way, through­out this post I will refer to the ‘mobile version/site/theme’; I’m aware that’s a loaded term as the site won’t work on many mobile devices, but I’m using it pure­ly as a con­ve­nient short­hand for ‘hand­held device that sup­ports media queries’.

Basic first, enhanced second

One of the biggest require­ments of mak­ing a mobile site is to keep it as light as pos­si­ble; don’t load any page assets that you don’t need. On we use large back­ground images, which would slow down the load­ing time notice­ably on mobile devices which aren’t wifi con­nect­ed, as well as eat­ing up data allowances.

Many sites which pio­neered the use of media queries have built a desk­top ver­sion first, and then used media queries to hide assets from mobile browsers. This is not opti­mal, because using display:none means only that the asset isn’t shown — but it is still loaded. The only way to not load an asset is to not include it in your stylesheet. The way I achieved this is by mak­ing the mobile stylesheet the default, and adding in the heav­ier page assets for the desk­top theme using a media query:

<link href="style.css" media="screen" rel="stylesheet">
<link href="desktop.css" media="screen and (min-device-width: 768px)" rel="stylesheet">

So the default stylesheet is the one you see on the mobile device, and devices with larg­er view­ports get the extras. The rea­son I chose 768px for the min­i­mum device width was main­ly to accom­mo­date the iPad and any sim­i­lar tablets that appear in future. We decid­ed that iPad users should get the full site expe­ri­ence, and as the iPad’s short­er screen side has a width of 768px, that’s the fig­ure we chose. Any device with a low­er res­o­lu­tion gets the mobile version.

Very old browsers that don’t sup­port media queries (sup­port table) will also see the mobile ver­sion of the site; that’s not a prob­lem, as they still get access to all of the con­tent. The mobile site is in no way infe­ri­or to the desk­top site; although it is miss­ing some of the func­tion­al­i­ty (notably the mul­ti­ple views for the port­fo­lio) it has all of the same con­tent, but is bet­ter suit­ed to a small­er screen.

Remember Internet Explorer

Mod­ern browsers have sup­port­ed media queries for some time now, but IE9 is the first ver­sion of Inter­net Explor­er to do so. To accom­mo­date that you need to add a con­di­tion­al com­ment to load the desk­top stylesheet for IE8 and below:

<!--[if lt IE 9]>
<link href="desktop.css" media="screen" rel="stylesheet">

The image and object problem

I’ve already men­tioned how to not load back­ground assets, but unfor­tu­nate­ly there’s no easy way to not load ele­ments in the markup, such as img or object, which could be quite heavy. This is some­thing still suf­fers from; although the images in the blog posts on the home page are not shown, they’re still down­loaded in the background.

Look­ing at ways around this will be the next step of the project. One approach we’re con­sid­er­ing is replac­ing images on the serv­er side with an emp­ty ele­ment, like: 

<div class="img" data-height="100" data-src="image.png" data-width="100" />

And then using JavaScript to rebuild them for the desk­top ver­sion, per­haps like:

    var imgHeight = $(this).data('height');
    var imgSrc = $(this).data('src');
    var imgWidth = $(this).data('width');
    var thisImg = $('<img height="'+imgHeight+'" src="'+imgSrc+'" width="'+imgWidth+'">');

I haven’t actu­al­ly test­ed this code, it’s just off the top of my head; but that’s the basic prin­ci­ple I’d be apply­ing. The advan­tage of this is that the mobile ver­sion does­n’t have to load extra images; the only real down­side is that users with JS dis­abled don’t see the images either. How­ev­er, as the images on our site are used for dec­o­ra­tion rather than illus­tra­tion, I think that’s an accept­able loss.

The sec­ond part of this issue is where we do want to show images, such as on the indi­vid­ual blog posts and port­fo­lio projects, but we’ve had to resize large images in the brows­er rather than serve up mobile-opti­mised ones. A way around this could be to use a ser­vice like tinyS­rc to serve resized images; ini­tial tests have thrown up a few issues which would mean it’s prob­a­bly not ide­al, but we real­ly haven’t looked into this too deeply yet.

JavaScript media queries

As well as pro­vid­ing rel­e­vant CSS rules to the desk­top and mobile themes, I also need­ed to pro­vide rel­e­vant JavaScript func­tions. To do this I used the JS equiv­a­lent of the device-width media fea­ture, which is screen.width, and made a ternary oper­a­tor which works on the same width val­ue as min-device-width:

var screenWidth = (screen.width  768) ? true : false;

So if I want­ed to use a script only on the mobile theme (as I did to move the nav­i­ga­tion from the top of the page to the bot­tom, for exam­ple) I would use this:

if(!screenWidth) { ... }

Media queries can’t be an afterthought

Prob­a­bly the most impor­tant point I learned was that if you’re plan­ning to use media queries, that deci­sion must be made at the very start of the project, because it affects not only the way you write your CSS, but also your markup. In order to make pages that adapt eas­i­ly to dif­fer­ent device view­ports, you must make deci­sions about how to mark up your con­tent in a way that allows for that adaptation.

Through­out the project I test­ed on both desk­top and mobile con­cur­rent­ly, mak­ing sure that the way I’d cod­ed for one did­n’t impact bad­ly on the oth­er. If I’d built for desk­top first and mobile sec­ond (or vice ver­sa) I would have had to make many changes to exist­ing code, which would have had a very neg­a­tive impact on my time.

One thing I did­n’t get right was the print stylesheet; it should have been con­sid­ered from the begin­ning and devel­oped at the same time as the oth­er stylesheets, which meant I could have fac­tored in the com­mon rules when decid­ing in which stylesheet to place them. As this did­n’t hap­pen, I end­ed up dupli­cat­ing a lot of rules from the screen stylesheets.

59 comments on
“Using Media Queries in the Real World”

  1. Your stu­pid site does­n’t work when resized down in a desk­top brows­er. I don’t know how your try­ing to make it “sym­pa­thet­ic to small-screen devices” but it isn’t very robust or respon­sive. I would­n’t be so proud if I were you.

    Also the site as a whole looks absolute­ly hor­ri­ble in all lat­est ver­sion of Chromi­um. Espe­cial­ly the top navigation.

  2. Def­i­nite­ly a log­i­cal step for media queries.

    Still the fact does remain that there is no way of effec­tive­ly con­trol­ling markup. I can’t imag­ine it’s too hard to come up with a php based solution.

  3. The prob­lem with doing any­thing on the serv­er side is that it becomes effec­tive­ly about browser/platform sniff­ing rather than device inde­pen­dent. We did explore that option, but the dis­ad­van­tages out­weighed the advan­tages — on this project, at least.

  4. I’m real­ly fond of this sort of “mobile first” approach. I’ve seen a few oth­er sites take a sim­i­lar approach, most notably Yiibu and Jere­my Kei­th’s Tweak­ing Huff­duf­fer.

    I attempt­ed some­thing sim­i­lar on my own site last month.

    What excit­ing times to be in web design!

  5. […] Using Media Queries in the Real World » Bro­ken Links […]

  6. […] own tri­als and tribu­la­tions with respon­sive design con­cepts. That means we should expect lots of blog posts and tweets regard­ing frus­tra­tions and accom­plish­ments. So keep read­ing and keep cre­at­ing. I, for […]

  7. Quick ques­tion for you Peter — how does that min­i­mum device width play with the iPhone 4/Nexus One and S in land­scape mode? Does it still achieve the desired effect?

  8. @Loz Despite the larg­er res­o­lu­tions (Galaxy S is 480x800, iPhone 4 is 640x960), both still dis­play the mobile site in land­scape mode. I haven’t real­ly looked into why this is, but I’m pre­sum­ing that device-width is cal­cu­lat­ed from the short­er side.

  9. […] Using Media Queries in the Real World […]

  10. This device width stays the same when you switch to land­scape mode. It is not updat­ed to reflect the wider screen you now have avail­able.” — PPK refers to iOS in his arti­cle, but it might very well be true for Android phones (can’t check, I don’t own either one of them). If I under­stand this cor­rect­ly, device-width i.e. on an iPhone 3 is always 320px, even in land­scape mode where the actu­al width is 480px.

    Here’s anoth­er ques­tion for you: If you split CSS files and include them the way you pro­posed above, are they not even loaded on a small­er device or are they just not being exe­cut­ed? Because if they’re just not being exe­cut­ed, it might be wis­er to keep them in one CSS file (using @media there) to save some requests. (Yes, there might be cas­es in which it would still be a good idea to split them because a sin­gle CSS file could get huge.)

  11. @Matthias — Yes, this is also true of Android phones — or my phone, at least, and I’d imag­ine it’s consistent.

    My under­stand­ing of the issue is that you split the CSS files then they are not loaded at all; I ini­tial­ly con­sid­ered putting all of the rules in the same file, but I read some­where — and I can’t remem­ber where — that if a CSS file is loaded, all of its assets are also loaded, regard­less of whether they’re used or not. That said, my usu­al pref­er­ence is to split files anyway.

  12. Great post, one small sug­ges­tion is that in your JS you could do this..

    var screenWidth = (screen.width < 768);

    Instead of

    var screenWidth = (screen.width < 768) ? true : false;

  13. I do not agree Toby,

    var screen­Width = (screen.width < 768) ? true : false;

    is more clearly.

    Also as Lewis men­tioned I think serv­er side script is the best solu­tion to fix the mark-up prob­lem. There are some libraries out there that are quite accu­rate on these checks. I guess the chance these get it wrong is small­er then some­one not hav­ing javascript enabled.

    Still I like your approach of putting the mobile ver­sion first and add stuff as the device gets “stronger”.


  14. you could put the images as back­ground images. They are load­able via CSS.

  15. @Holger: That’s an inter­est­ing idea; the prob­lem is that the site is man­aged by CMS and the edi­tors can place images any­where they want, but I could pre-process the infor­ma­tion and replace an img ele­ment with a div with a back­ground image, and use CSS to hide that… good approach, I’ll think it over some more!

  16. I love the idea of pre­sent­ing mobile stylesheets first, and I’ve been using it in many of my web sites and apps a lot the past cou­ple months.

    Unfor­tu­nate­ly, from my tests, both the stylesheets above, basic.css, and desktop.css, will be down­loaded on mobile browsers. I’ve test­ed iOS, WebOS, Android, FF Mobile and Opera and they all down­load both stylesheets. Desk­top browsers also down­load both stylesheets if you set min-device-width to some­thing high like 6000 px.

    It works prop­er­ly because the mobile devices don’t apply the desk­top styles, but that weight is still down­loaded to the devices.

    The only solu­tion I have is to use some JS and detect the screen width and load the desktop.css dynamically.

  17. Hi Peter,

    I had a few thoughts whilst read­ing your article:

    - You could use a javascript to dynam­i­cal­ly load in dif­fer­ent script sets depend­ing on whether it was the mobile or desk­top ver­sion. If the desk­top ver­sion used jQuery but the mobile ver­sion did not this could save a lot of bandwidth.

    - You could load mobile ver­sions of the images and then use javascript to turn them into the desk­top versions.

    - It would be inter­est­ing to do resource load­ing based upon band­width rather than screen width (par­tic­u­lar­ly giv­en mobile teth­er­ing, iPhone hotspots, and the like.

    I’ve put some exam­ple code and longer expla­na­tions here:

    What do you think?

  18. […] read­ing the post “Using Media Queries in the Real World” by Peter Gasston, I switched around my media query to tar­get desk­top sizes rather than mobile sizes. It makes more […]

  19. Thank you for this clean and clear expla­na­tion. I have been exper­i­ment­ing with using media queries to react to screen size than pick­ing up that alter­ation in CSS via jQuery and chang­ing the DOM or run­ning an ajax request back to the serv­er to alter the page. I post­ed an exam­ple updat­ed with your help­ful infor­ma­tion in this post: Mobile Detec­tion with CSS and jQuery: Part 2.

    BTW, I can­not seem to sub­scribe to your RSS feed…it is giv­ing me an error.

  20. @Ryan: First of all, I don’t know why you have to be so aggres­sive; your crit­i­cism would be more accept­able if you could use some basic social grace. Any­way, it does­n’t change when you resize the brows­er because I’ve used the device-width media fea­ture, not the width fea­ture; by your not real­is­ing that, I know you haven’t read the arti­cle prop­er­ly. As for the head­er com­ments, what do you mean by that? That’s a very non-spe­cif­ic crit­i­cism, so how should I address it?

    @Thomas J Bradley: The tests we ran indi­cat­ed that the stylesheets were being ignored; I’ll have to dou­ble check our results. Cer­tain­ly the page load speed increased by quite a lot.

    @Mark Wales: Great arti­cle, we’ll be look­ing in to your pro­pos­als as part of a sec­ond round of changes.

    @Jen: Thank you. I’ll read your arti­cle over the week­end when I have more time — I’ll also look into the RSS problem.

  21. @Mark Wales — I read through your arti­cle again. Points 1 & 2 are very good; it’s true that on there are still more opti­mi­sa­tions to be made, and we don’t need most of jQuery. This might be a good place to use yepnope.js. I think your third point is a good idea, but not sure if it works in prac­tice. Would be great if mobile browsers had an API to access to find out if Wifi were con­nect­ed or not.

    @Jen — I read your arti­cle too. Inter­est­ing approach, which may be use­ful to us in future revi­sions. Also, the RSS feed should hope­ful­ly be sort­ed out now.

  22. Great con­cept and I think the meth­ods that Thomas J. Bradley and Mark Wales ref­er­ence are great. How­ev­er, one minor(?) issue I found with using JavaScript to inject a ‘deskop’ ver­sion CSS file. When test­ing on a fair­ly slow serv­er, I found there was a notice­able FOUC from before and after the ‘deskop’ CSS was applied. Any­one else notice this?

    FYI — the ‘desk­top’ stylesheet is get­ting applied to the DOM before the page loads, so it’s not a case of me wait­ing for a DOM ready event or win­dow onload event to fire.

  23. I real­ly like the approach of cre­at­ing a base for small­er screen sizes first, too, as it means that old mobiles don’t have to be capa­ble of read­ing media queries to have styling that’s not prob­lem­at­ic for them.

    Any more to add on whether or not “desktop.css” in your exam­ple is down­loaded (along with any back­ground images) by devices with device-widths low­er than 768px?

  24. Also, I’d be inter­est­ed to hear what your issues with tinyS­rc were — looks very inter­est­ing. Thanks.

  25. @David Oliv­er — Haven’t had time to run more tests yet, but will post the results here when I do. I’m pret­ty con­fi­dent that even if a stylesheet gets loaded, the assets with­in it don’t.

    Also, the first image we test­ed with tinyS­rc did­n’t scale well as it was too tall (it was, admit­ted­ly, a *very* tall image). Also, we have con­cerns about what hap­pens if their serv­er goes down; they have no sup­port agree­ments in place. For per­son­al use I’m sure it’s very good.

  26. Your image replace­ment via JavaScript tech­nique will pre­vent browsers from per­form­ing a look-ahead, spec­u­la­tive down­load of the resource, impact­ing load time a fair bit.

  27. @Nicholas Shanks — Thanks Nicholas, we’ve yet to imple­ment it (we’re look­ing at a serv­er-side solu­tion right now) but we’ll bear that in mind.

  28. @David Oliv­er — Very rough pre­lim­i­nary tests show that when using media queries, all CSS files get loaded but the con­tents of any which don’t match the require­ments of the giv­en media fea­tures are ignored. So no back­ground loading.

  29. Thanks Peter. I want to test this myself, too, but it’s good to hear your pre­lim­i­nary results for comparison.

  30. I sup­pose it also depends on how each brows­er does it. Although a brows­er we test might not load back­ground images, per­haps a dif­fer­ent brows­er on a mobile will.

  31. Great arti­cle, Peter. Thanks! I’ve been doing a lot of work and test­ing with MQ late­ly as well (des­per­ate­ly need to blog it). I can weigh in on a cou­ple issues here. My hus­band blogged our find­ings about what CSS doc­u­ments, and resources inside them, are down­loaded in Dec on his blog Assort­ed Garbage.

    Also, I don’t know if you’ve seen it before, but there’s some very cool exper­i­men­ta­tion going on by Scott Jehl and Fil­a­ment Group on respon­sive (mobile first) images. It may help solve your image chal­lenge. I’m very inter­est­ed in this approach since it’s more agile and allows you to keep things acces­si­ble (with alt text, etc). I haven’t been able to try it on a project yet, how­ev­er. (And there’s not a sim­i­lar project with objects, AFAIK.)

    (Also, for those that are inter­est­ed, there’s a tiny script—Responsive.js—by the same folks. It will detect browsers that don’t sup­port MQ and then add the support.

    My biggest chal­lenge with this new devel­op­ment par­a­digm is, like you say, build­ing it this way from the start. I receive comps (I do front-end devel­op­ment) that are typ­i­cal­ly cre­at­ed for desk­top first—with dead­lines. So sad­ly, much of the time I end up doing the desk­top first, and then try­ing to switch things around in the end—which can be con­fus­ing. It makes me wish that either A) I was a design­er myself or B) We could train more design­ers in this method more quickly. 

    Thanks for help­ing to get the word out. :)

  32. @Stephanie: thanks for the links — inter­est­ing. The more I read and think about this top­ic, the more I find myself pre­fer­ring a serv­er-side approach of first deter­min­ing if the access­ing device is a mobile and then serv­ing the appro­pri­ate stylesheets based on that rather than rely­ing on media queries to server/not serv­er CSS and CSS images. Although your hus­band’s tests were great to read about, as a com­menter point­ed out there are oth­er devices we need to know about and keep­ing on top of all that would be a full time job!

    At the moment, my plan is to use to tell me if the device is 1) an old mobile, 2) a new­er mobile/smartphone, 3) a tablet or con­sole or 4) some­thing else (full fat desk­top assumed). Based on this, I’ll serv­er up stylesheets and media queries tai­lored to either 1, 2, 3 or 4 along with media queries to han­dle ori­en­ta­tion and view­port size for 2, 3 and 4.

    Scot­t’s respon­sive images does­n’t appeal as it relies on Javascript, which I’m pret­ty sure a lot of old mobiles won’t sup­port (and it’s those and slow con­nec­tion speeds that would ben­e­fit from hav­ing small images the most).

    I hope to have a set up in place to test all this some­time soon… will blog about it.

  33. I seem to have a habit of typ­ing ‘serv­er’ instead of ‘serve’!

  34. Thanks every­one for all the com­ments; I’m def­i­nite­ly going to have to return to this top­ic. I found this site, btw, which tests dif­fer­ent meth­ods for downloading/hiding images using media queries:

  35. @David — I type serv­er ALL the time as well. lol On respon­sive images — it actu­al­ly serves the small one if JS isn’t avail­able, and the large one is added through the data-full­src attribute. Scott says, “Ide­al­ly, this could enable devel­op­ers to start with mobile-opti­mized images in their HTML and spec­i­fy a larg­er size to be used for users with larg­er screen res­o­lu­tions — with­out request­ing both image sizes, and with­out UA sniffing.”

    @Peter — thanks for the link. Check­ing it now. (I set my MAMP serv­er up to log over the week­end, so as soon as today’s dead­line is over, I’m going to test some oth­er ideas.

    It’s always inter­est­ing, isn’t it? :)

  36. Hel­lo,

    I’ve since cre­at­ed a lit­tle JavaScript that swaps mobile images for desk­top images. You sim­ply but all the mobile images in a “mobile” direc­to­ry and all the desk­top images in a “desk­top” direc­to­ry. Pop the mobile images into the HTML and then the JavaScript will swap them. It’s a bit more basic than the Respon­sive Images script men­tioned above, but it works pret­ty well.


  37. […] Using Media Queries in the Real World Bro­ken Links – This entry was post­ed in deli­cious book­marks and tagged CSS, html5, Javascript, mobile, tools, web­dev. Book­mark the perma­link. ← Book­marks for April 25th Book­marks for April 28th → […]

  38. This response is a bit pre­ma­ture. A few on this site have talked about serv­er side pro­cess­ing, PHP, ASP, to han­dle this prob­lem. That was my orig­i­nal approach also, but I’ve changed every­thing to JavaScript.

    The biggest prob­lem with media queries is the lack of a default for browsers that do not sup­port the tech­nol­o­gy. The best I’ve found so far to fix this issue is to write a par­al­lel set of stylesheet for non media query browsers and they enclose the media query links in an IF state­ment like, if brows­er is greater than IE8 use these links, if brows­er is not greater than IE8 use these links. That approach total­ly sucks! How do you test for the prop­er ver­sions of IE , FF , Opera, Chrome, etc at the same time?

    My site that uses JavaScript is not com­plete, but it is pub­lished if you’d like to look at it. The ver­sion on the web is for flu­id design and it does not include the links when the page gets too nar­row to allow for side nav­i­ga­tion. I’m plan­ning to pub­lish a par­al­lel site that is fixed width as soon as I fin­ish the top navigation.

    I solved the default prob­lem by defin­ing all the style sheets but one as alter­nate style sheets. If the brows­er does not sup­port JavaScript, the sin­gle non alter­nate style sheet becomes the default. If the brows­er does sup­port JavaScript, and it runs cor­rect­ly, the last step is to run through the list of stylesheet and acti­vate / deac­ti­vate the sheets to select the cor­rect one based on page width.

    I’m offer­ing the script and also the MyS­SI process as free­ware for non com­mer­cial use if any­one is interested.

  39. […] […]

  40. Thanks so much for sug­gest­ing putting the mobile css first and then the screen css. I was try­ing to work the oth­er way around and was hav­ing a bunch of difficulty.

  41. […] and the desk­top expe­ri­ence through media queries, an idea dis­cussed by both Luke Wrob­lews­ki and Peter Gasston. Com­bin­ing this approach with some­thing like Adapt.js or 320 and up could improve per­for­mance for […]

  42. What I would like to pro­pose is that added to the CSS3 spec is the abil­i­ty to on a basic lev­el con­trol the DOM so that we can rearrange the source order of content.

    Rely­ing on javascript or a serv­er side solu­tion to shift the source order of your site seems so restrictive.

    I believe CSS3 would be suit­ed to this because it’s very much a layout/design design issue.

    I know this can be achieved on a basic lev­el using posi­tion­ing and floats, but it’d make life a lot eas­i­er if this was pos­si­ble. Thoughts anyone? :-)

  43. @Glen,

  44. […] and adding to the code that you have. But if you do choose this route, then you will need to start with the small­est res­o­lu­tion first, because this is the best prac­tice for cod­ing a responsive […]

  45. I am hav­ing trou­ble try­ing to build a site which relies on pro­vid­ing con­tent based upon media query.

    Works great in IE9 and all oth­er browsers. Display:none is not rec­og­nized in IE8 and low­er. I’ve tried strip­ping down the page to load­ing just one of the 3 (mobile, tablet, and desk­top) style sheets, and <IE9 dis­plays the entire page content.

    Could some­one see what I’m doing wrong?

    Here’s the page w media query:

    Here’s the page with media query and my attempt to load a sin­gle css file for IE 8 or lower:

    I don’t under­stand why IE 8 is not hid­ing the con­tent I’ve set as dis­play: none in the var­i­ous css files.

    Thanks in advance.

  46. Kristi,

    I notice that at least one of the items you’re hid­ing in CSS uses a selec­tor with ‘head­er’ in it, which is a new HTML5 ele­ment. Do you have the HTML5 JS shiv includ­ed in your Mod­ern­izr? This allows IE to style the HTML5 elements.

  47. I had past­ed most of the javascript to the bot­tom of the page and 

    Was there. I’ve moved it to the top, before the CSS call-ins, but that does­n’t seem to make a difference.

    I’ve updat­ed the page. The Mod­ern­izr is from zipped pack­age. I’ve uploaded the mod­ern­izr, jquery and func­tions javascript from that ZIP pack to the site. 

    Unfor­tu­nate­ly, I appar­ent­ly know just enough to be dan­ger­ous :) so I’m not sure if oth­er things should be changed and if every­thing is being start­ed in the functions.js that should be.

    I so appre­ci­ate your reach­ing out to help!

  48. Sor­ry this dropped out of the above post.

  49. !--[if lt IE 9]
    script src="http: // /svn/ trunk/ html5.js"

    removed and spaced added to URL in an attempt to get this to show. Any­way, it’s in the head­er of the doc­u­ment now.

  50. […] and the desk­top expe­ri­ence through media queries, an idea dis­cussed by both Luke Wrob­lews­ki and Peter Gasston. Com­bin­ing this approach with some­thing like Adapt.js or 320 and up could improve per­for­mance for […]

  51. I am hav­ing some trou­ble try­ing to run a JS func­tion only on mobile using your example: 

    var screenWidth = (screen.width < 768) ? true : false;
    if(!screenWidth) {...}

    Essen­tial­ly I have a list of bios that dis­play nor­mal­ly on desk­top, but on mobile they need to be in an accordion.

    This is what I have:

    Any sug­ges­tions on try­ing to get this to work?

    trewknowledge [September 14th, 2012, 20:24]

  52. […] and up project page explains it like this “Inspired by Using Media Queries in the Real World by Peter Gasston, ‘320 and Up’ is a device agnostic,one […]

  53. @TrewKnowledge A bet­ter way to do JS media queries is with the matchMedia() method, like so:

    var screenWidth = window.matchMedia('(max-width: 768px)');
    if (screenWidth.matches) { ... }

    Your demo seems to be work­ing fine.

  54. How can we load media query before stan­dard css? Cur­rent­ly cur­rent styles is tak­ing over media css files.

  55. […] to fit the dif­fer­ent brows­er sizes of the var­i­ous devices that they will be viewed upon, and to avoid the dis­con­nect that often comes from think­ing pri­mar­i­ly about the desk­top design and the rest of the respon­sive iter­a­tions as an after­thought (see espe­cial­ly Stephanie (Sul­li­van) […]

  56. […] fit the dif­fer­ent brows­er sizes of the var­i­ous devices that they will be viewed upon, and to avoid the dis­con­nect that often comes from think­ing pri­mar­i­ly about the desk­top design and the […]

  57. […] Using Media Queries in the Real World […]

  58. […] Using Media Queries in the Real World A good intro­duc­tion to media queries as well as some imple­men­ta­tion ideas and JavaScript based alternatives. […]

  59. […] Using media queries in the real world […]