Shiny CSS-only iPhone Buttons
Just a quickie: I came up with these CSS-only iPhone-style buttons as part of a bigger pet project I’m working on. They make heavy use of -webkit-gradient instead of the typical PNG-based solution you typically see out there, such as in iUI.
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.
Webfonts and Mobile Devices
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):
- 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. - 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).
- Eyeball it. In some cases, the criteria above aren’t met, so the
@font-faceimplementation 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:
- 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 whengetComputedStyle()is called.) - What’s worse, is that when this situation occurs, if no fallback
font-familyis specified, the text will render with the browser’s defaultfont-family(as you’d expect), but it does so at less than the default font size. Fortunately, if you specify a fallback value in thefont-familydeclaration, it will render the fallback typeface at the correct size, so always remember to pick a degradation path for your fonts. - 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
@mediaquery 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. - 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-facedeclaration, 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.
On not knowing _why
Sometime this morning, Why the Lucky Stiff basically erased himself from the Internet. He deleted his Twitter & Github accounts, as well as took down the sites at his various domains, including his massively influential “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 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.
Links for June the Second, 2009
- 1 line CSS Grid Framework — Distilling a CSS framework into one line is an interesting experiment, in that it shows essentially what all of the other (bigger than one line) frameworks are doing. Also, if you look at the markup of a site that was built using it, it serves as a pretty good reductio ad absurdum against CSS frameworks.
- jQuery Performance Rules — A useful collection of best practices that can speed up your jQuery code by non-trivial amounts. I’ll admit that I’m often guilty of sticking the bulk of my code inside of
$(function(){...}). - jQuery: Inline caching for selectors — If you’re taking the advice of the article linked above and caching your jQuery objects, take a look at this technique for keeping those cached objects available throughout your app without polluting the global namespace (hint: it uses closures).
- Procs And Blocks And Anonymous Functions — Speaking of closures, this is a decent rundown of the various uses of closures in Ruby.
zsh: Scratching a geeky itch
I’ll apologize right out of the gate for the resemblance this post bears to one Rafe Colburn made today. We sit across from each other at work, and we’re both diving into zsh at the moment, so cross-pollination was probably 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 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.
The Eyes of March
This month, I’ll be participating in the Experimonth project. The main thrust of Experimonth is that for every month in 2009, participants will do something they (probably) don’t normally do every day in that month and record their experience. For instance, January’s experiment was to eat only raw foods for the entire month.
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.
