Media Queries: Getting Specific

Posted by: Stephanie Donahue on November 19, 2014

This is the final part of the 3 part series on media queries. In this section, we will talk about some specifics of using these handy little things.

Device Specific Media Rules

Some devices allow you to even further target specific browsers by adding the browser specific extension in front of the rule; such as:

@media only screen and (-webkit-min-device-pixel-ratio: 2)
and (min-width: 320px),
only screen and (min–device-pixel-ratio: 2)
and (min-width: 320px),
only screen and (-o-min-device-pixel-ratio: 2/1)
and (min-width: 320px),
only screen and (min-device-pixel-ratio: 2)
and (min-width: 320px) {
/* small screen styles go here */

Media Query Downside

There are some in the community who pose a good argument against using media queries. Their argument rests on the fact that adding more code to address mobile responsiveness makes the page load slower (more code = bigger file size) which affects the speed at which a site loads on a mobile device.

Along this same vein is the downside to using relative media sizing techniques, such as dynamic cropping of photos or photo scaling. To use this technique, you typically load the full version of the image and scale it back using relative sizing. But the problem again with this approach is that you’re loading a full version of the image on mobile devices which translates into more bandwidth and more latency on mobile devices which typically have less hardware capabilities and bandwidth.

Both points are valid. The only thing I can say is that it really depends on your project. Some clients don’t mind the extra couple milliseconds of load time while others are sticklers. Regardless, if you’re doing very complex calculations already on your site, the queries may just push the latency over its tipping point.  I suggest looking at minimizing size where and whenever possible, but be mindful of reality.


There is a right way to test and a wrong way to test media queries (or more specifically, a responsive site in general). Let’s start with the wrong way.

The wrong way is to resize the browser window on a laptop in hopes of duplicating the smaller display. This is a bad approach because the responsive frameworks that drive the responsive actions of the site typically are dependent on device width to dictate which media queries to call. But when you resize the browser window, you’re merely changing the width and not device width. This isn’t a problem so long as you call out the width and device width both in the media feature test of your media query. But it is problematic when you or your chosen framework or grid system only test against one feature and not both.

That was the wrong way, now what is the right way to test a responsiveness? The most obvious way is test the site on all the various devices. But if your budget doesn’t allow for such eloquent testing, don’t fret because you have other options.

One is to use the built-in capabilities that come with newer versions of browsers. One example is the Responsive View button in Firebug in Firefox. While this feature does allow you to resize the data as if viewing it from another device, the problem with this approach is that you’re still only testing a specific user agent. So while it might look fine in Firebug, it might be broken on an iPad.

Another option is to use some of the responsive apps and emulators on the web.  A good one is ProtoFluid. However, the drawback I often come across with these is that if your site has SSL (https://), or if you don’t have anonymous access enabled (authentication required), these often won’t work.

I find that a combination of all three testing methods works best for me. I start with Firebug, then test in all the browsers, then on all the mobile devices I have, and then when I’m out of local options, I resort to trying the emulators.

Media Query Tips

One common mistake people make is to neglect to include the meta tag in their header. This tag looks like this:

<meta name=”viewport” content=”width-device-width” />

This tag needs to exist somewhere in your head tag or things will get wacky for you. Your content would not behave responsively and you’ll get a ‘zoomed out’ version of the content instead of a responsively redesigned page. What this tag does is sets the viewport to be the device-width instead of page width. So when you use relative sizing on images or other scalable content, it will be based on the width of the screen on the device your viewing the site through (viewport) instead of the page width.  If you were to neglect doing this, your relative sizing wouldn’t work as intended.

Another ‘bug’ to watch out for is when it comes to CSS 2.0 browsers. To get the responsive actions in IE8 and older browsers, you can use JavaScript to fix the shortcomings of CSS3. A good library for this retrofit is the CSS3-mediaqueries-js library found here: .

This file just requires you referencing it in your header and using media queries as you do with CSS3. Works like a charm for IE5 and up, Firefox 1 and up, and Safari 2 and up. If for some reason you come across something that this library doesn’t cover, you can always look up the support options for the query in question at .

Another interesting tip when it comes to verifying if media queries are supported comes from Brad Czerniak in the comments of this article: Here, Brad is suggesting to register to a media query that always evaluates to true, such as:

@media screen and (max-width:7000px){#hours thead{width:5px;}}

After you have your always true media query (assuming their screen size isn’t bigger than 7000px), you can use JavaScript to test the width of the class you set in the media query as such:

If($(window).width() <= 640 && $(“#hours thead”).css(“width”) == “5px”){}

If the if statement passes, you know your device supports media queries. If it doesn’t, you can register an else clause and apply whatever fixes you need to.

Mobile First Approach

One final note to wrap up this blog series is a sort of rehash of an earlier statement.  When designing a responsive site, always start with mobile first.  This means to apply styles for mobile devices in your core CSS code and then use media queries for all devices bigger than your smallest. This route also makes controlling the cascading effect of CSS easier to work with. Trust me from experience that cascading

More Resources

Good one

Topics: Enterprise Content Management

    Recent Posts