Green Ideas

Respon­sive web design is unde­ni­ably the new hot­ness in CSS. If you’re not famil­iar with the tech­nique, go and read Ethan Marcotte’s amaz­ing arti­cle over on A List Apart. What Mar­cotte has cre­ated is a way to cre­ate one design that adapts to dif­fer­ent res­o­lu­tions using media queries.

There are count­less advan­tages to build­ing sites in this way, but arguably the most com­pelling rea­son is the abil­ity to share one lay­out across both desk­top and mobile browsers. How­ever, if you’re new to mobile devel­op­ment there are a cou­ple of tricks you’ll need to use in order to make this work. It wasn’t really in the scope of Marcotte’s arti­cle to cover the mobile-specific aspects of his tech­nique, so I fig­ured a quick post was in order to fill in the gaps.

The exam­ple site we’ll be look­ing at is a hypo­thet­i­cal site for food­ies called Fork’d. When you look at it in a nor­mal sized desk­top browser, It’s got a ver­ti­cal nav­i­ga­tion list and three columns of con­tent. If you resize the win­dow to be a fair bit nar­rower, you’ll see that the floats dis­ap­pear, and the nav­i­ga­tion as well as all of the con­tent is lined up in a sin­gle col­umn. This is the lay­out we want our mobile users to see. How­ever, what they’re actu­ally going to see is this:

the site renders very small

For­tu­nately, we just need a tiny sprin­kling of pixie dust to make this work the way we expect it to. We’ll just add this meta tag to our page:


<meta name="viewport" content="width=device-width, initial-scale=1.0">

(For way more info on view­ports, check out Apple’s doc­u­men­ta­tion on the sub­ject.)

Once we put that in place, the Fork’d site ren­ders like this:

the site renders at the correct resolution

Per­fect! We now have one lay­out that works across dif­fer­ent desk­top screen res­o­lu­tions as well as (high-end) mobile devices, and the only extra trick we had to employ was to add a sin­gle meta tag.

Ugly font-variant bug

Here’s an annoy­ing lit­tle bug that man­i­fests when you try to set a CSS font-variant prop­erty (say, small-caps) with a font that doesn’t pro­vide the requested vari­ant. For instance, here is some text in League Gothic, pulled in via @font-face:

Sample of league gothic text, rendered normally

League Gothic doesn’t have its own small caps vari­ant. So what hap­pens when you tell the browser to give you one any­way? Here it is with font-variant: small-caps applied as ren­dered in Firefox:

Sample of league gothic small caps, rendered correctly in Firefox

So far, so good. But here’s what you get when you add small caps to League Gothic in Webkit:

Sample of league gothic small caps, which falls back to the default font in Webkit

Whoops! Webkit-based browsers (I tested this in Safari, Webkit Nightly, and Chrome for OSX), when they don’t find the spec­i­fied vari­ant in the font itself, just go to the next font in the stack. In this case, it’s the browser’s default font.

So which behav­ior is cor­rect? The CSS2 spec essen­tially left it up to imple­men­tors to decide whether or not they would dynam­i­cally scale the font to imple­ment small caps. CSS3 removes the ambiguity:

If a gen­uine small-caps font is not avail­able, user agents should sim­u­late a small-caps font, for exam­ple by tak­ing a nor­mal font and replac­ing the low­er­case let­ters by scaled upper­case char­ac­ters. (CSS fonts mod­ule level 3)

Although a typo­graphic purist might take issue with this behav­ior (Bringhurst rails against the prac­tice of “rolling your own” vari­ants by dynam­i­cally scal­ing the exist­ing face), this is what the spec says browsers are sup­posed to do. And in fact, this is what Fire­fox does. Webkit, on the other hand, checks each font in the stack in order until it finds one that sup­plies the desired vari­ant. As in the exam­ple above, if there’s noth­ing else in the stack, it will fall back on the browser’s default font.

Unfor­tu­nately, there aren’t really any workarounds for this bug. But it should serve to remind you yet again that it’s super-important to put a good deal of thought into your font stack. Always try to build a stack where all of the fonts are as sim­i­lar as pos­si­ble, so when some­thing like this hap­pens, your design doesn’t break too badly.

For ref­er­ence, or if you’d like to see how your browser of choice han­dles these cases, here are some test cases together on a sep­a­rate page.

Install Curb Gem on Ubuntu

A quickie:

If you’re get­ting the old

ERROR: Failed to build gem native extension.

error while try­ing to install the curb gem, you’ll need to install libcurl4-openssl-dev (along with the ruby1.x-dev pack­age for the ver­sion of Ruby you’re running).

Font-face Support Table

I’ve been sit­ting on this for a lit­tle while, so I thought I’d just go ahead and pub­lish it. For an in-depth expla­na­tion of how I got these results, check out this post. In a nut­shell, it shows that all of the main desk­top browsers sup­port some kind of @font-face for­mat, so as long as you use some­thing like the Bul­let­proof font-face syn­tax, your fonts will ren­der in all of the the major browsers (e.g. those with > 3% mar­ket share). On mobile, it’s still a Mobile Safari-only party.