Responsive Web Design for Mobile

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.

This entry was posted on July 2nd, 2010. It was tagged as , , , , and has no comments.

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.

This entry was posted on April 22nd, 2010. It was tagged as , , , , , and has no comments.

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).

This entry was posted on March 4th, 2010. It was tagged as , and has no comments.

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.

Web­font for­mat sup­port by browser
Embed­ded Open Type (.eot) True­Type (.ttf) Open­Type (otf) Web Open Font For­mat (.woff) SVG (.svg)
Mobile Browsers1
1 I haven’t had a chance to test Mozilla’s portable offerings
Mobile IE (≤ WinMo 6.5) No No No No No
Opera Mini (≤ v4.2) No No No No No
Opera Mobile (9.7 Beta WinMo) No No No No No
Palm WebOS No No No No No
Mobile Safari (3.1) No No No No Yes!
Android (≥ 2.2 SDK) No Yes Yes No No
Desk­top Browsers (Incom­plete. I’ll be fill­ing this in more over time)
IE (≥ 5.5) Yes No No No No
Fire­fox No Yes (≥ 3.5) Yes (≥ 3.5) Yes (≥ 3.6) No
Safari No Yes (≥ 3.1) Yes (≥ 3.1) No Yes (≥ 3.1)
Opera No Yes Yes No Yes
Chrome No No No No Yes (≥ 3.0)

This entry was posted on December 4th, 2009. It was tagged as , , , , , and has 3 comments.

Shiny CSS-only iPhone Buttons

Just a quickie: I came up with these CSS-only iPhone-style but­tons as part of a big­ger pet project I’m work­ing on. They make heavy use of -webkit-gradient instead of the typ­i­cal PNG-based solu­tion you typ­i­cally see out there, such as in iUI.

The CSS is here, and be sure to check out the exam­ple but­tons.

The one thing I’m not crazy about when you use these styles on an actual device is that the nor­mal :active state doesn’t get trig­gered, so I kind of had to half-ass it with a :hover so you’d see the “active” style as the but­ton sheet eases out (if you’ve wired the tran­si­tions together).

Enjoy, and please let me know if you find them useful.

This entry was posted on November 27th, 2009. It was tagged as , , , and has no comments.

Webfonts and Mobile Devices

If you pay even a lit­tle atten­tion to emerg­ing trends in Web Stan­dards, you’re no doubt famil­iar with the explo­sion in inter­est in the CSS @font-face prop­erty. This prop­erty goes back to CSS2, and has been sup­ported in IE as far back as 5.5, but @font-face sup­port is being added at a rapid pace to other browsers, hence the recent surge of interest.

As some­one who spends his days devel­op­ing for mobile plat­forms, I wanted to check on how @font-face sup­port was pro­gress­ing in mobile browsers. Read on to see what I found out.

Method­ol­ogy

I put together a test page I used to check the extent of @font-face support.

I made test ele­ments and sep­a­rate font fam­i­lies for each font for­mat being tested (e.g. there’s a font fam­ily called “Chunk­Five SVG” that will only be applied to the span#SVG test ele­ment. View source on the sam­ple page for more details). I checked for @font-face sup­port with three cri­te­ria (two automated):

  1. Ask each test ele­ment what font-family it thinks it is being ren­dered with. This is done via the window.getComputedStyle() method (and why I’m stick­ing with test­ing W3C com­pli­ant browsers at the moment). If all goes well, the return value should be some vari­ant of ChunkFive.
  2. Check to see if the ren­dered text is wider than text ren­dered in the browser’s default font. For the test to pass, it has to be wider, since there are font size bugs in Mobile Safari (see below).
  3. Eye­ball it. In some cases, the cri­te­ria above aren’t met, so the @font-face imple­men­ta­tion is incor­rect, but it’s close enough to be saved with some extra TLC.

I also included a test case based on Paul Irish’s Bul­let­proof @font-face syn­tax as a bit of a san­ity check and for the sake of hav­ing a less con­trived exam­ple. Lastly, I threw in sam­ples of Cufon and sIFR text, just for comparison.

All that said, here’s what I came up with.

Results

Mobile Safari 3.0

Sup­port for @font-face in Mobile Safari is cur­rently bro­ken in sev­eral frus­trat­ing ways:

  1. Cer­tain for­mats (e.g. TTF & OTF), when applied, falsely report that they have been suc­cess­fully applied. That is, if you check the value of font-family from get­Com­put­ed­Style() on that ele­ment, it will return the @font-face value, even though it doesn’t ren­der as such. (Update 11/13: As Paul Irish cor­rectly pointed out in the com­ments to this post, Opera is actu­ally the only browser that returns the font that’s actu­ally used when getComputedStyle() is called.)
  2. What’s worse, is that when this sit­u­a­tion occurs, if no fall­back font-family is spec­i­fied, the text will ren­der with the browser’s default font-family (as you’d expect), but it does so at less than the default font size. For­tu­nately, if you spec­ify a fall­back value in the font-family dec­la­ra­tion, it will ren­der the fall­back type­face at the cor­rect size, so always remem­ber to pick a degra­da­tion path for your fonts.
  3. Another issue with text size arises if you use the SVG for­mat to get around the lack of sup­port for other for­mats on the iPhone. While you can indeed use SVG fonts in your font-face rules on the iPhone, text ren­dered in SVG fonts will ren­der at smaller than expected sizes. So if you opt for this strat­egy, just plan for this con­se­quence, and cor­rect the font sizes accord­ingly. Desk­top browsers that sup­port SVG fonts (Safari & Chrome) don’t exhibit this bug, so you need to tar­get this font-size fix to mobile browsers. You can eas­ily han­dle this case with a @media query in your stylesheet. Users of the Bul­let­proof Syn­tax will see this bug, since it will fall through to SVG on Mobile Safari.
    Mobile Safari renders SVG text too smallSVG fonts on Mobile Safari ren­der too small out of the box.
  4. Another (pos­si­bly more aca­d­e­mic) issue is that call­ing getComputedStyle() on text ren­dered with an SVG font will not return the font-family value in your @font-face dec­la­ra­tion, even though it ren­ders with that font fam­ily. This could prove trou­ble­some if you’re using Javascript to test the suc­cess of your font rendering.

So if you need to use @font-face on Mobile Safari today, you should be sure to include an SVG ver­sion in your @font-face dec­la­ra­tion, and you should patch any text size bugs with a @media query. (If you’re not famil­iar with @media queries, you should read up on them.)

Inci­den­tally, Opera 10 on the desk­top also shows a slight vari­a­tion in font-size when using SVG fonts as well. How­ever, since it sup­ports True­Type and Open­Type for­mats, this shouldn’t cause any par­tic­u­lar issues if you’re using the bul­let­proof syn­tax (that’s why it’s bul­let­proof, yo).

Android 2.0 SDK

Short and not so sweet: There is no sup­port in the Android 2.0 SDK for any web­font for­mat. If you’re tar­get­ing Android, use Cufon.

Palm WebOS

Like Android, there is cur­rently no sup­port what­so­ever for @font-face in WebOS. Addi­tion­ally, in my (not at all exten­sive) tests, Cufon didn’t even appear to work at all (as in no text was rendered).

Sum­mary

In short, if you want your mobile site to join the Nice Web Type band­wagon, you have a lit­tle more work to do than for your desk­top site. Of all of the mod­ern WebKit-based mobile browsers, only Mobile Safari pro­vides any kind of @font-face sup­port. And even that sup­port is buggy and incom­plete. How­ever, if you are aware of these lim­i­ta­tions ahead of time (which you ought to be by this point in the post), you have a cou­ple of tricks in your back pocket to keep things run­ning smoothly.

What’s Next?

In the next lit­tle while, I’ll extend these tests to cover IE on WinMo and also do a sim­i­lar write-up for @font-face sup­port in desk­top browsers and tab­u­late all of the results in a lit­tle more for­mal manner.

Update: In case any­one wants to take a look under the hood of these tests with­out jump­ing through hoops in Fire­bug or View Source, the test code is up on Github.

This entry was posted on November 10th, 2009. It was tagged as , , , , , and has 7 comments.

On not knowing _why

Some­time this morn­ing, Why the Lucky Stiff basi­cally erased him­self from the Inter­net. He deleted his Twit­ter & Github accounts, as well as took down the sites at his var­i­ous domains, includ­ing his mas­sively influ­en­tial “Why’s Poignant Guide to Ruby.”

Of course, what you don’t know is why he did it. And nobody could know that unless/until _why him­self decides to come back and tell us, for lack of a bet­ter word, why. Nat­u­rally, that hasn’t stopped folks from guess­ing out loud. At the moment, the pre­vail­ing “wis­dom” in the var­i­ous threads on Hacker News is that _why’s dis­ap­peared him­self as a response to his iden­tity being dis­closed last month. If that’s the case, then I humbly encour­age those respon­si­ble to for­ni­cate them­selves with some­thing rusty. There were no death threats involved, so we’re not at the Kathy Sierra level of offense, but the end result for the web com­mu­nity is the same: some­body who obvi­ously cared a lot about mak­ing the web a bet­ter place for every­one has decided it’s not worth the abuse.

It should be pretty obvi­ous why I don’t feel par­tic­u­larly inclined to link back to any of the trolls out there who, even if they’re not directly respon­si­ble for _why’s deci­sion, are directly respon­si­ble for the web being less of a great place to live and work. That said, I do want to point to John Resig’s “eulogy” for _why, mostly because I wish I could be as pos­i­tive as he is about this whole thing.

This entry was posted on August 19th, 2009. It was tagged as , , , and has no comments.

Links for June the Second, 2009

  • 1 line CSS Grid Frame­work — Dis­till­ing a CSS frame­work into one line is an inter­est­ing exper­i­ment, in that it shows essen­tially what all of the other (big­ger than one line) frame­works are doing. Also, if you look at the markup of a site that was built using it, it serves as a pretty good reduc­tio ad absur­dum against CSS frameworks.
  • jQuery Per­for­mance Rules — A use­ful col­lec­tion of best prac­tices that can speed up your jQuery code by non-trivial amounts. I’ll admit that I’m often guilty of stick­ing the bulk of my code inside of $(function(){...}).
  • jQuery: Inline caching for selec­tors — If you’re tak­ing the advice of the arti­cle linked above and caching your jQuery objects, take a look at this tech­nique for keep­ing those cached objects avail­able through­out your app with­out pol­lut­ing the global name­space (hint: it uses closures).
  • Procs And Blocks And Anony­mous Func­tions — Speak­ing of clo­sures, this is a decent run­down of the var­i­ous uses of clo­sures in Ruby.

This entry was posted on June 2nd, 2009. It was tagged as , , , , , and has no comments.

zsh: Scratching a geeky itch

I’ll apol­o­gize right out of the gate for the resem­blance this post bears to one Rafe Col­burn made today. We sit across from each other at work, and we’re both div­ing into zsh at the moment, so cross-pollination was prob­a­bly inevitable.

The other day, I switched my shell from bash to zsh. Just like Rafe, I read the Fried CPU post about zsh, and was con­vinced to give it a whirl. It’s been in the back of my mind for a while now, since I’ve notice that a lot of peo­ple whom I respect (Ryan Bates, for one) are using it, but the con­cise list of really pow­er­ful fea­tures in the Fried CPU arti­cle was the tip­ping point. I’ll admit that, never hav­ing switched shells before, I thought it was going to be a heck of a lot more com­pli­cated than just typ­ing chsh and replac­ing “/bin/bash” with “/bin/zsh” in the con­fig file that pops up. Had I known it would be that easy, I would’ve tried it a lot sooner.

At first, I tried copy­ing huge chunks out of the zshrc & other zsh con­fig files that Joe Fer­ris main­tains in a repo at Github, but even­tu­ally decided I’d get more out of this exper­i­ment if I took more bite-sized chunks out of other peo­ples con­fig­u­ra­tions, and only added them to my own when I under­stood what they were doing.

That’s when things got out of hand.

When I was copy­ing bits of my old bash con­figs over to my zshrc, I noticed how dis­or­ga­nized all of my dot­files were–not just the shell ones, but my irbrc, and vim & emacs con­figs, etc., etc., etc. So I basi­cally decided to scrap all of them and take the same approach to them as I was tak­ing with my shell con­figs. So basi­cally, I’m start­ing over with Unix, and slowly rebuild­ing what I’m hop­ing will be a super-organized and super-optimized envi­ron­ment for future work and play.

If you’re inter­ested in see­ing how things develop, you can fol­low along with my dot­files repo on Github. But what I’m sure will be infi­nitely more inter­est­ing will be to start on your own adven­ture in Unix con­fig­u­ra­tion. If you go down that road, here are some of the resources I’ve used in rebuild­ing my environment:

  • Joe Ferris’s config_files repo: I men­tioned this before, but it’s worth men­tion­ing again, due to its being awesome.
  • dotfiles.org: User-conributed dot­files for just about every *nix-based util­ity that uses a text-based con­fig­u­ra­tion file.
  • irb & script/console tips: Obvi­ously these are only use­ful to Ruby­ists, but if you swing that way, the­ses are well worth check­ing out. Ever since I first saw the SQL gen­er­ated by an ActiveRe­cord query show up in someone’s script/console, I’ve cov­eted that func­tion­al­ity. Dan Croak shows how it’s done.
  • Dr. Nic also has some great irb tips
  • Finally, I cribbed a git-aware prompt from this screen­cast. A very neat trick.

So yeah, it’s been really fun get­ting back to basics with my Unix con­figs. That said, I have had one small hic­cup in this process. After going through all of this with my OSX ter­mi­nal, I went to switch my shiny new Ubuntu JeOS VM’s shell over to zsh, but found that after doing so, my delete key wasn’t behav­ing like a back­space as it had been doing when I was using bash. Appar­ently this is a known issue when using zsh or screen over ssh. I still haven’t found a good workaround for this, and so am still using bash in Ubuntu.

All in all, switch­ing from bash to zsh has been an extremely reward­ing expe­ri­ence, and def­i­nitely one I’d rec­om­mend to any­one look­ing to change up their rou­tine and learn some­thing new and useful.

This entry was posted on April 4th, 2009. It was tagged as , , , and has no comments.

The Eyes of March

This month, I’ll be par­tic­i­pat­ing in the Expe­r­i­month project. The main thrust of Expe­r­i­month is that for every month in 2009, par­tic­i­pants will do some­thing they (prob­a­bly) don’t nor­mally do every day in that month and record their expe­ri­ence. For instance, January’s exper­i­ment was to eat only raw foods for the entire month.

This month’s exper­i­ment, called “The Eyes of March” involves tak­ing or mak­ing a pic­ture of some­thing every day. If you want to fol­low along, there’s a Flickr group for the project.

Of course, every exper­i­ment needs a hypoth­e­sis, so here’s mine: I’m guess­ing (and indeed hop­ing) that being on the look­out for things to take pic­tures of every day will make me more mind­ful of the visual impact of things that I look at all the time and don’t pay very much atten­tion to. So if by the end of the month, I’ve been able to look at the things around me and notice some­thing new and or impor­tant about even a few of them, then the exper­i­ment will have been a suc­cess. If any­thing like that hap­pens, I’ll be sure to make a note of it here.

This entry was posted on March 1st, 2009. It was tagged as , , and has no comments.

« Older Entries