Responsive Images Test

Update 2012-04-25: Seeing as how the script actually checks for the rendered width of the image, not the actual browser width, I was stuck trying to figure out how to keep the “medium” size for images at 300×300 but still serve those for users all the way up to 500px. I originally had a max-width: 100% declaration for images (which is a fairly common practice for images in responsive designs), but reviewing the Viewport Industries example I’ve removed that declaration up until the media query I’ve set at 600px. This way I can set a width threshold of 500px for the medium size, even though the native size of the image is 300px wide. Because the image is now allowed to scale past its native size the script now correctly detects when it has scaled past the 500px threshold I’ve set, and then it serves up the larger size. That way most smaller-screen devices get the medium size.


This is a test of the responsive images technique outlined by Viewport Industries. Originally I thought that the Responsive Enhance script was checking the screen width, but looking at the script it appears to check the width of the image. So for this example WordPress generates a 300px wide “medium” version which I’ve modified to B & W for easy identification. When the image renders at smaller than 300px 500px you should get a black & white version of the image, everyone else should get the full-size version. That’s how I understand it, at least.

Feet

Debugging is All About Baselines

This started out as a quick post for a particularly obscure CSS/Media Query bug for IE 7—or so I thought. It ended up being a quick reminder on why debugging is all about limiting the number of variables at play.

I was encountering a weird situation where a background shorthand stack was failing in IE 7, but only when wrapped in a media query. I was using modernizr 2.0.6, which had respond.js baked in. So a background declaration like this was failing:

@media only screen and (min-width: 500px) {
    ul li {
        background: rgb(233,233,233);
        background: rgba(233,233,233,.8);
    }
}

If I took away the RGBA declaration the background color would be properly applied. Other properties seemed to take properly, so I was left scratching my head.

With that information in hand, I set about trying to isolate the issue. I downloaded a fresh copy of HTML5Boilerplate and set to work. It ended up that I couldn’t replicate the bug I had been facing when boiling the markup down to a single unordered list and minimal CSS. But I was also seeing all declarations in my media queries fail. After some thrashing about, I read the release notes and this jumped out:

Respond.js is no longer available by default.

Well, I’ll be. So that explained why my test cases were failing in IE 7 and 8: the media query polyfills were no longer included with modernizr. I pulled a fresh copy of respond.js, threw that in, and the bug I started out with no longer occurred. That meant that my bug was probably a result of an older respond.js version, or a result of that being wrapped up in modernizr.

So, a hard lesson re-learned about debugging: When investigating a bug, try to make sure you’re working from a baseline that mirrors the situation where you found it. I was starting from a baseline that didn’t mirror the one that had the bug, since I was using modernizr 2.5.3 (vs 2.0.6). In this case using a newer version of modernizr compounded the confusion further because it no longer included respond.js, a major difference.