MW Henry Home Ideas

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.

This entry was posted on November 27th, 2009. It was tagged as CSS, iphone, mobile, 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 CSS, font-face, typography, web standards, webfonts, 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 manners, ruby, _why, 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 closures, javascript, jquery, performance, ruby, 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 irb, unix, zsh, 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.