Web­font for­m

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.

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.

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.

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.

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.

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.