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.

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.

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

The CSS is here, and be sure to check out the example buttons.

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

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

If you pay even a little attention to emerging trends in Web Standards, you’re no doubt familiar with the explosion in interest in the CSS @font-face property. This property goes back to CSS2, and has been supported in IE as far back as 5.5, but @font-face support is being added at a rapid pace to other browsers, hence the recent surge of interest.

As someone who spends his days developing for mobile platforms, I wanted to check on how @font-face support was progressing in mobile browsers. Read on to see what I found out.

Methodology

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

I made test elements and separate font families for each font format being tested (e.g. there’s a font family called “ChunkFive SVG” that will only be applied to the span#SVG test element. View source on the sample page for more details). I checked for @font-face support with three criteria (two automated):

1. Ask each test element what font-family it thinks it is being rendered with. This is done via the window.getComputedStyle() method (and why I’m sticking with testing W3C compliant browsers at the moment). If all goes well, the return value should be some variant of ChunkFive.
2. Check to see if the rendered text is wider than text rendered 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. Eyeball it. In some cases, the criteria above aren’t met, so the @font-face implementation is incorrect, but it’s close enough to be saved with some extra TLC.

I also included a test case based on Paul Irish’s Bulletproof @font-face syntax as a bit of a sanity check and for the sake of having a less contrived example. Lastly, I threw in samples of Cufon and sIFR text, just for comparison.

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

Results

Mobile Safari 3.0

Support for @font-face in Mobile Safari is currently broken in several frustrating ways:

1. Certain formats (e.g. TTF & OTF), when applied, falsely report that they have been successfully applied. That is, if you check the value of font-family from getComputedStyle() on that element, it will return the @font-face value, even though it doesn’t render as such. (Update 11/13: As Paul Irish correctly pointed out in the comments to this post, Opera is actually the only browser that returns the font that’s actually used when getComputedStyle() is called.)
2. What’s worse, is that when this situation occurs, if no fallback font-family is specified, the text will render with the browser’s default font-family (as you’d expect), but it does so at less than the default font size. Fortunately, if you specify a fallback value in the font-family declaration, it will render the fallback typeface at the correct size, so always remember to pick a degradation path for your fonts.
3. Another issue with text size arises if you use the SVG format to get around the lack of support for other formats on the iPhone. While you can indeed use SVG fonts in your font-face rules on the iPhone, text rendered in SVG fonts will render at smaller than expected sizes. So if you opt for this strategy, just plan for this consequence, and correct the font sizes accordingly. Desktop browsers that support SVG fonts (Safari & Chrome) don’t exhibit this bug, so you need to target this font-size fix to mobile browsers. You can easily handle this case with a @media query in your stylesheet. Users of the Bulletproof Syntax will see this bug, since it will fall through to SVG on Mobile Safari.
   SVG fonts on Mobile Safari render too small out of the box.
4. Another (possibly more academic) issue is that calling getComputedStyle() on text rendered with an SVG font will not return the font-family value in your @font-face declaration, even though it renders with that font family. This could prove troublesome if you’re using Javascript to test the success of your font rendering.

So if you need to use @font-face on Mobile Safari today, you should be sure to include an SVG version in your @font-face declaration, and you should patch any text size bugs with a @media query. (If you’re not familiar with @media queries, you should read up on them.)

Incidentally, Opera 10 on the desktop also shows a slight variation in font-size when using SVG fonts as well. However, since it supports TrueType and OpenType formats, this shouldn’t cause any particular issues if you’re using the bulletproof syntax (that’s why it’s bulletproof, yo).

Android 2.0 SDK

Short and not so sweet: There is no support in the Android 2.0 SDK for any webfont format. If you’re targeting Android, use Cufon.

Palm WebOS

Like Android, there is currently no support whatsoever for @font-face in WebOS. Additionally, in my (not at all extensive) tests, Cufon didn’t even appear to work at all (as in no text was rendered).

Summary

In short, if you want your mobile site to join the Nice Web Type bandwagon, you have a little more work to do than for your desktop site. Of all of the modern WebKit-based mobile browsers, only Mobile Safari provides any kind of @font-face support. And even that support is buggy and incomplete. However, if you are aware of these limitations ahead of time (which you ought to be by this point in the post), you have a couple of tricks in your back pocket to keep things running smoothly.

What’s Next?

In the next little while, I’ll extend these tests to cover IE on WinMo and also do a similar write-up for @font-face support in desktop browsers and tabulate all of the results in a little more formal manner.

Update: In case anyone wants to take a look under the hood of these tests without jumping through hoops in Firebug or View Source, the test code is up on Github.

Of course, what you don’t know is why he did it. And nobody could know that unless/until _why himself decides to come back and tell us, for lack of a better word, why. Naturally, that hasn’t stopped folks from guessing out loud. At the moment, the prevailing “wisdom” in the various threads on Hacker News is that _why’s disappeared himself as a response to his identity being disclosed last month. If that’s the case, then I humbly encourage those responsible to fornicate themselves with something 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 community is the same: somebody who obviously cared a lot about making the web a better place for everyone has decided it’s not worth the abuse.

It should be pretty obvious why I don’t feel particularly inclined to link back to any of the trolls out there who, even if they’re not directly responsible for _why’s decision, are directly responsible 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 positive as he is about this whole thing.

The other day, I switched my shell from bash to zsh. Just like Rafe, I read the Fried CPU post about zsh, and was convinced 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 people whom I respect (Ryan Bates, for one) are using it, but the concise list of really powerful features in the Fried CPU article was the tipping point. I’ll admit that, never having switched shells before, I thought it was going to be a heck of a lot more complicated than just typing chsh and replacing “/bin/bash” with “/bin/zsh” in the config file that pops up. Had I known it would be that easy, I would’ve tried it a lot sooner.

At first, I tried copying huge chunks out of the zshrc & other zsh config files that Joe Ferris maintains in a repo at Github, but eventually decided I’d get more out of this experiment if I took more bite-sized chunks out of other peoples configurations, and only added them to my own when I understood what they were doing.

That’s when things got out of hand.

When I was copying bits of my old bash configs over to my zshrc, I noticed how disorganized all of my dotfiles were–not just the shell ones, but my irbrc, and vim & emacs configs, etc., etc., etc. So I basically decided to scrap all of them and take the same approach to them as I was taking with my shell configs. So basically, I’m starting over with Unix, and slowly rebuilding what I’m hoping will be a super-organized and super-optimized environment for future work and play.

If you’re interested in seeing how things develop, you can follow along with my dotfiles repo on Github. But what I’m sure will be infinitely more interesting will be to start on your own adventure in Unix configuration. If you go down that road, here are some of the resources I’ve used in rebuilding my environment:

• Joe Ferris’s config_files repo: I mentioned this before, but it’s worth mentioning again, due to its being awesome.
• dotfiles.org: User-conributed dotfiles for just about every *nix-based utility that uses a text-based configuration file.
• irb & script/console tips: Obviously these are only useful to Rubyists, but if you swing that way, theses are well worth checking out. Ever since I first saw the SQL generated by an ActiveRecord query show up in someone’s script/console, I’ve coveted that functionality. Dan Croak shows how it’s done.
• Dr. Nic also has some great irb tips
• Finally, I cribbed a git-aware prompt from this screencast. A very neat trick.

So yeah, it’s been really fun getting back to basics with my Unix configs. That said, I have had one small hiccup in this process. After going through all of this with my OSX terminal, 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 behaving like a backspace as it had been doing when I was using bash. Apparently 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, switching from bash to zsh has been an extremely rewarding experience, and definitely one I’d recommend to anyone looking to change up their routine and learn something new and useful.

This month’s experiment, called “The Eyes of March” involves taking or making a picture of something every day. If you want to follow along, there’s a Flickr group for the project.

Of course, every experiment needs a hypothesis, so here’s mine: I’m guessing (and indeed hoping) that being on the lookout for things to take pictures of every day will make me more mindful of the visual impact of things that I look at all the time and don’t pay very much attention to. So if by the end of the month, I’ve been able to look at the things around me and notice something new and or important about even a few of them, then the experiment will have been a success. If anything like that happens, I’ll be sure to make a note of it here.