found drama

I pushed version 0.7 of Orin (this blog’s theme) on April 11th, and considering what happened between then and now… Well, I meant to make an announcement and I guess it just needed to wait about a month.

At any rate: version 0.7 of Orin refactors the blog as a “mobile first” responsive design. It was a fun little experiment. I suppose Orin is not strictly “mobile first”, because if it was, then it would have been designed with mobile devices in mind from the very beginning. However, my refactor of the design attempted to account for my mobile audience by putting the mobile-targeted styles as the default/baseline styles. If you go through the commit, history ¹ you can follow the changes and see the challenges in this kind of refactor. Some reflections:

many examples are actually “mobile second”

A lot of the tutorials, resources, blog posts, and other places with sample “responsive” code seem to claim to be “mobile first” but then their media queries look like this:

@media all and (max-width: 1023px)

In other words: apply special rules for the mobile devices. On the one hand, this makes sense: in the research I did, the mobile devices are far more likely to support the CSS3 media queries. On the other hand, you’re also forcing the (less powerful) mobile devices to run all the code, and process all the CSS from all the rules. ^{2 3} As I took my cues from a lot of these resources as I worked my way through the learning, I found myself writing the code this way first.

margins (also padding)

When something “mysterious” was throwing me off in the layout, it was almost always something to do with the margins. (Or the padding.) It isn’t so much that these are calculated differently (they’re not) — but places where I’d always used margins to achieve certain results seemed to fall apart for me. Especially with orientation changes.

device-width and maximum-scale

Get familiar with these. When you’re just cutting your teeth on mobile, it’s easy to forget how different the pixel density on the mobile device is from your non-mobile desktop. Experiment. Play with these settings to get a feel for how they affect the layout. ⁴

Sass/Compass organization

This is an area where I smell future experiments. During the early phases of developing version 0.7, I found that I would usually put the media query rules inline with the baseline style (for example) — i.e., immediately after it. While this was convenient, it also meant that Sass/Compass was compiling an @media rule every time it encounters one, instead of rolling them up. At first I was annoyed by this, but the more I thought about it, the more I realized that this was the correct behavior of the Sass compiler. If it attempted to roll them up based on @media rule matches… well: that’s the kind of “magic” I’ve found myself advocating against these past few months. So I withdrew my (unspoken) complaint against the Sass compiler and decided to re-organize the code. In a lot of ways, this actually turned into a clever solution.

conditional comments as an @media rule hack

In my quest to minimize the number of @media rules in the output, I stumbled across the strategy of moving the @media rules out of the CSS and into the mark-up. This offered a couple of advantages. First, I’m serving less CSS to the mobile devices. The WordPress style.css is the mobile stylesheet; the desktop styles get triggered by the @media rule in the second/supplementary stylesheet — thus only actually downloading those styles when we are confident that we need them and are on a screen resolution that can support them.

But whither Internet Explorer 8? Poor IE8, which needed no special CSS love in previous versions of Orin is suddenly “stuck” with the “mobile version’s” styles. If only there was a way to apply the desktop styles that we’re otherwise delivering via a media query…? Oh right: conditional comments! It’s not a “pure” solution; it’s not feature detection. I’d even go so far as to call it “cheating”. But it was cheating that got me what I wanted, and with only a minimum of fuss. ⁵

Try it out!

As I mentioned at the beginning of this post, I pushed the changes and deployed the updated theme on April 11th. There is a good chance you have seen this in action already. ⁶ If not… The site now looks decent on a variety of mobile devices. And I am happy to admit that it didn’t actually take all that long.

1. Relevant SHAs: d308f13fc0, 9eaeb307f7, 9b455240a4, and a9a587353c[↩]
2. As an aside: I’ll admit that I need to do more research in this area. I may be over-estimating the amount of processing the device does. Perhaps it only applies a given block of CSS after processing the whole stylesheet and determining which ones actually apply. And/but what if those overrides are furnished from another stylesheet all together? What if… what if…? I am making some assumptions, but most of them seem like reasonable assumptions.[↩]
3. Also: I’ve seen the “rules” called “breakpoints” in a lot of places. And I cannot figure out why this is. We’re not debugging, they’re not breakpoints.[↩]
4. And as an aside to all this: a third-generation iPad did not seem to report its device-width in the way I expected. Anyone else notice this?[↩]
5. After all, the stylesheet delivered from the conditional comments is the same one that would have been delivered if IE8 supported the media query.[↩]
6. I know of at least one person that contacted me about it to compliment me on the improvement.[↩]

About Rob Friesel