Responsive web design is undeniably the new hotness in CSS. If you’re not familiar with the technique, go and read Ethan Marcotte’s amazing article over on A List Apart. What Marcotte has created is a way to create one design that adapts to different resolutions using media queries.
There are countless advantages to building sites in this way, but arguably the most compelling reason is the ability to share one layout across both desktop and mobile browsers. However, if you’re new to mobile development there are a couple of tricks you’ll need to use in order to make this work. It wasn’t really in the scope of Marcotte’s article to cover the mobile-specific aspects of his technique, so I figured a quick post was in order to fill in the gaps.
The example site we’ll be looking at is a hypothetical site for foodies called Fork’d. When you look at it in a normal sized desktop browser, It’s got a vertical navigation list and three columns of content. If you resize the window to be a fair bit narrower, you’ll see that the floats disappear, and the navigation as well as all of the content is lined up in a single column. This is the layout we want our mobile users to see. However, what they’re actually going to see is this:
Fortunately, we just need a tiny sprinkling 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 viewports, check out Apple’s documentation on the subject.)
Once we put that in place, the Fork’d site renders like this:
Perfect! We now have one layout that works across different desktop screen resolutions as well as (high-end) mobile devices, and the only extra trick we had to employ was to add a single meta tag.
Ugly font-variant bug
Here’s an annoying little bug that manifests when you try to set a CSS font-variant property (say, small-caps) with a font that doesn’t provide the requested variant. For instance, here is some text in League Gothic, pulled in via @font-face:
League Gothic doesn’t have its own small caps variant. So what happens when you tell the browser to give you one anyway? Here it is with font-variant: small-caps applied as rendered in Firefox:
So far, so good. But here’s what you get when you add small caps to League Gothic in Webkit:
Whoops! Webkit-based browsers (I tested this in Safari, Webkit Nightly, and Chrome for OSX), when they don’t find the specified variant 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 behavior is correct? The CSS2 spec essentially left it up to implementors to decide whether or not they would dynamically scale the font to implement small caps. CSS3 removes the ambiguity:
If a genuine small-caps font is not available, user agents should simulate a small-caps font, for example by taking a normal font and replacing the lowercase letters by scaled uppercase characters. (CSS fonts module level 3)
Although a typographic purist might take issue with this behavior (Bringhurst rails against the practice of “rolling your own” variants by dynamically scaling the existing face), this is what the spec says browsers are supposed to do. And in fact, this is what Firefox does. Webkit, on the other hand, checks each font in the stack in order until it finds one that supplies the desired variant. As in the example above, if there’s nothing else in the stack, it will fall back on the browser’s default font.
Unfortunately, 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 similar as possible, so when something like this happens, your design doesn’t break too badly.
For reference, or if you’d like to see how your browser of choice handles these cases, here are some test cases together on a separate page.
Install Curb Gem on Ubuntu
A quickie:
If you’re getting the old
ERROR: Failed to build gem native extension.
error while trying to install the curb gem, you’ll need to install libcurl4-openssl-dev (along with the ruby1.x-dev package for the version of Ruby you’re running).
Font-face Support Table
I’ve been sitting on this for a little while, so I thought I’d just go ahead and publish it. For an in-depth explanation of how I got these results, check out this post. In a nutshell, it shows that all of the main desktop browsers support some kind of @font-face format, so as long as you use something like the Bulletproof font-face syntax, your fonts will render in all of the the major browsers (e.g. those with > 3% market share). On mobile, it’s still a Mobile Safari-only party.
