A blog by Matt Henry
A quickie:
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).
I’ve been sitting on this for a little while, so I thought I’d just go ahead and publish it. For an in-depth explanation of how I got these results, check out this post. In a nutshell, it shows that all of the main desktop browsers support some kind of @font-face format, so as long as you use something like the Bulletproof font-face syntax, your fonts will render in all of the the major browsers (e.g. those with > 3% market share). On mobile, it’s still a Mobile Safari-only party.
| Embedded Open Type (.eot) | TrueType (.ttf) | OpenType (otf) | Web Open Font Format (.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.0 SDK) | No | No | No | No | No |
| Desktop Browsers (Incomplete. I’ll be filling this in more over time) | |||||
| IE (≥ 5.5) | Yes | No | No | No | No |
| Firefox | 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) |
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.
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.
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):
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.@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.
Support for @font-face in Mobile Safari is currently broken in several frustrating ways:
@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.)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.@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.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).
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.
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).
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.
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.
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.
$(function(){...}).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:
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, 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.
Hey, you know what can be a real pain in the tail? CSS rounded corners. Of course there are battle-tested, workhorse solutions out there, like sliding doors, or a handful of Javascript-based alternatives. But rounded corners are such a common element of web design and seem like a natural extension of the designer’s existing toolkit that it only makes sense that there should be a way to implement them with pure CSS. The good news is that border-radius is indeed coming in CSS3. The better news is that you can start using it today, as long as you’re only targeting Gecko & Webkit. Before we get to that though, let’s look at the way it’s supposed to work according to the spec.
As you might expect, the border-radius property is used a lot like border. That is, you can specify one value for each corner (border-radius: 10px;), one value per corner (border-radius: 1px 2px 3px 4px;), or values for opposite corners (border-radius: 5px 10px). It actually gets more complicated, since in addition to describing corners with one radius (i.e. those with semi-circular curves), you can make elliptically rounded corners by naming two radii. For more detail on this, take a look at the draft spec. Lastly, you can use a property for each corner, border-top-left-radius: 2em;, etc. So, assuming there aren’t any major changes in the spec, expect this to be what gets implemented as part of CSS3, and what you’ll ultimately using in your code.
But what about now? Here? Today? It happens that two of the standards-aware, forward-thinking rendering engines have developed proprietary extensions to CSS that should stand in for border-radius until certain ambiguities in the spec can be resolved, and the property is implented according to the standard. So if you want to use border-radius in your code today, you’ll have to use both the Mozilla– and Webkit-specific CSS properties. Fortunately, both of the proprietary extensions work in the current major releases of their respective browsers.
If you’re making a box with four corners of the same radius, the syntax is the same in Mozilla and Webkit:
-moz-border-radius: 10px; /* 4 corners of radius = 4px*/ -webkit-border-radius: 10px; /* Same as Mozilla */
To specify different radii for each corner, things diverge somewhat.
/* Mozilla: */
-moz-border-radius: 1px 2px 3px 4px;
/* Webkit:
(The four declarations below amount to the
same thing as the single rule above) */
-webkit-border-top-left-radius: 1px;
-webkit-border-top-right-radius: 2px;
-webkit-border-bottom-right-radius: 3px;
-webkit-border-bottom-left-radius: 4px;
And that’s the guts of it. So to make a tabbed navigation list, you would use a declaration along the lines of the following (and see the below code in action.):
li {
border: 1px solid #587402;
border-bottom: none;
border-radius: 0 10px 0 10px;
-moz-border-radius: 10px 10px 0 0;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 10px;
list-style-type: none;
float: left;
padding: .5em 1em 0 1em;
}
There you have it. But there are just a couple of other things I want to point out. If the container you’re rounding the corners of has only text content and a background in it, the background will clip to the rounded corners. And indeed, according to the spec, any the contents of a block-level element on which a border-radius is set should clip do the same as long as you set overflow: hidden on those contents. However, the implementations just aren’t there yet. Instead, with anything over and above plain HTML text (for instance, an img or iframe) inside such a container, the square corners will peek outside of the rounded container. (Example)
One solution would be to make the border thick enough that the corners of the inner element can’t poke through the outer border (like so). Though inelegant, this will work just fine if you don’t need everything to round nicely. And this method should suffice for whatever kind of content you’re trying to stuff into your nicely rounded box.
However, if it’s an image you’re putting in the box and you need the inner corners to be rounded as well as the outer corners, then the only answer (for now) is to set the image as a background. Still, if the language of the spec is any indication, it won’t always be this way.
For the poor soul who is trying to squeeze iframe content into a rounded corner box, you’re essentially out of luck at the moment. You can certainly use the thick border method I described above, but short of that, you’ll have to look to the bleeding edge. That is to say, you’ll need something which isn’t yet in any production-quality browser, but that is currently in the Webkit nightlies. I speak of the arcane methods of -webkit-mask-image. This property can take a png or an svg as its url, and pretty much anything you apply it to will play nice and clip to the shape of the image. See for yourself. Still, this last bit is obviously not anything anybody will be using in production code for some time to come.
After reading all of this, if nothing else, I do hope that you’ve come away with a better idea of some of the great things that the CSS working group has in store for you, the developer. But even moreso, hopefully there’s something in all of this mess that you’ll be able to put to use today.
I loved the first Condemned. It was loads of fun, and I can count on two fingers the number of games that I’ve found as legitimately scary. So I was looking very forward to the second installment. Having now played through the first level of Condemned 2: Bloodshot, let me offer a few preliminary thoughts about whether or not it lives up to the promise of its predecessor.
Graphically, it looks considerably better than Criminal Origins. This is to be expected, since the latter was a launch title for the 360, and the developers clearly didn’t know much about how to utilize the resources available to them. As such, the fact that the character models and animation have drastically improved is as expected as it is welcome.
I wish I could say that the gameplay has improved as much as the overall look of the game. Not so, I’m afraid. At least through the first part of the game, everything feels much easier. Let me expand on that. The first thing I noticed when going through the combat tutorial at the start of the game was that I didn’t really need to block to keep from getting clobbered. In the first game, encounters usually began with you having to block a 2x4 being swung at you by a lunging hobo. Then you’d have to watch your opponent and precisely time your blocks and parries until you had sent the bastard to wino hell. Each fight was intense, savage, and thrilling. This time around, however, if you notice a bad guy before he spots you, you could potentially just run up to him and punch him until he dies. Not fun. But hey, who needs intense combat, when you’ve got… minigames? Uh, no. Thanks to God of War and Resident Evil 4, game devs think that tacking a small rhythm minigame onto a fight is sufficient to take monotonous button mashing into something innovative. It’s not.
Unfortunately, the worst consequence of taking the grit out of the combat, is that the game has lost its white-knuckle edge. Playing through the first one was exhausting. Each shadow potentially hid one or more bloodthirsty crazies who could kill you pretty quickly if you weren’t ready for a fight, and the resulting tension was genuinely draining. For this outing, if you’re not worried that you’re a couple of whacks away from game over, the best you can hope for is a jump scare when the weird ash-monster explodes from the ceiling. It’s just not the visceral experience that I loved the first time around.
What I do like is the storytelling. I like that our hero has essentially become one of the lost souls he mercilessly battered in the first installment. I really like that from his (and the player’s) perspective, there isn’t any real indication that he hasn’t succumb to whatever it is that has caused half of his city’s population to turn into brutal psychopaths. Most of all, though, I really like the turn towards horror that this game takes right from the outset. The city is covered in oozing tar, skeletal ash-men lurk in the shadows, and the weird lip-ring dudes are giving you attitude in the most ominous way. Good stuff all. I just wish the gameplay was able to match the tone of the writing.
Overall, I have a lot of serious issues with Condemned 2 that I really hope will resolve themselves as I get a little further along. However, given how fantastic the first game was, I feel justified in being at least somewhat optimistic that they will.
And speaking of violent video games, Stephen King has come out against the proposed Massachusetts law that would lump violent games in with pornography as being “harmful to minors.” Indeed, he even namechecks RE4. This further supports my long-held suspicion that Stephen King is completely awesome.