Cache Rules Everything Around Me

For years, Firefox has enforced a strict same-origin policy for web fonts. This is the behavior recommended by the latest W3C Fonts Spec. As indicated by the spec, servers that you wish to host fonts on for another domain will need to be configured to respond with the appropriate Cross-Origin Resource Sharing (CORS) headers.

This behavior protects font publishers, but it also creates hassle for anyone using an external asset host or CDN. If the font asset response from your asset server doesn’t include CORS headers, those fonts will not render correctly in the browser. Usually an empty square will be displayed instead of the desired character.

There’s an old issue on Mozilla’s bug tracker where the decision to implement this as default behavior is discussed at length. As noted at the end of the thread, Chrome 37 (released to Stable on 8/26/14) now complies with the W3C spec. Because of this, it’s now more important than ever that your asset host is configured correctly.

If you use Cloudfront, this configuration is pretty straightforward as Amazon now offers full-fledged CORS support. After you configure Cloudfront to forward the Origin header, your origin server still needs to send the right headers – check out for server specific configuration instructions. With nginx I simply had to use the add_header directive. Once the origin server is responding with the right headers, you’ll need to manually bust the edge caches or generate a new asset manifest. You can see if the headers are there with curl --head.

One gotcha I ran into: Chrome does a preflight request before doing a GET for the font asset. If the preflight request doesn’t have CORS headers, the actual GET will show as canceled in the webkit network console. It was hard to tell what was going on because the network console doesn’t show preflight requests and curl --head shows the right headers (GET request without preflight). So, make sure you allow both GET and OPTIONS requests with the Access-Control-Allow-Methods header.

Is iOS 7 Pretty on the Inside?

Never thought I’d see something as ugly as the new iOS icon set on Apple’s front page. A few of them are alright. The white background on the Safari icon looks like it’s there by mistake. Seriously, when you accidentally save an icon with a white background instead of a transparent one, that’s what it looks like. This is what a circular icon on a white square makes me think of – especially when the icon itself looks like a product of MS Paint.

“They ripped off Microsoft” and similar accusations aside, the in-app screenshots do look pretty nice. The photos app stands out and the consistent content-first approach is refreshing. It’s been said that this is the most important aspect of the redesign. After all, you don’t actually spend time on the home screen – you launch your app and get out of there. Besides, with all the negative press these icons have been getting, Apple will almost certainly put some attention on them before the final release.

But at first glance, these new icons really do seem detrimental to the Apple brand. Anyone with a bit of design sense can tell how unappealing the new icons are. Even the gradients aren’t consistent – the mail icon sticks out like a sore thumb. They would be better off simply removing the gloss and gradient from many of their old icons. Some third party apps (Skype, LinkedIn, etc.) have already taken this approach. Betas are available for iOS 7, but most people won’t use it until the final release this fall. In fact, I’m sure a lot of people won’t see anything besides the new icon set before the final is available to install on their iThings. Apple has made this new icon set the most visible (if not the most important) aspect of iOS 7 by placing it on their homepage.

Read on →

Stop Pasting Code to Vendor/assets!

Use the Bower gem instead!

I prefer the bower gem over bower-rails because it defaults to placing everything in components/, instead of lib/ and vendor/. Using components/ is a nice cue to other developers that the project uses Bower.

Besides, Rails creates vendor/assets/javascripts/ and vendor/assets/stylesheets/ – this structure doesn’t make sense for many repositories that include CSS and Javascript. Use components/project_name/ instead.

Using OS X Media Keys With Web Applications

Last week I set out to find a way to use my macbook media keys to control web applications. Specifically, I wanted to use the play/pause and next/prev buttons with MinSub, the HTML5 player for Subsonic.

After a bit of googling, I found two solutions from Boris Smus. The first (Chrome-Media-Keys), works by adding JS event listeners to all Chrome tabs. There are a few problems with this:

  1. Pressing a media key doesn’t actually trigger keypress, but pressing F7-F9 does. This means that you need to invert those keys with FunctionFlip or similar, which breaks support for desktop media apps (you would need to push fn+play to control iTunes). I believe some non-mac keyboards will trigger keypress for their media keys.

  2. Possible performance issues because you are inserting JavaScript into every open Chrome tab.

  3. Lastly, this only works if Chrome is the active window. The whole point of media keys is to let you control music regardless of what software you are currently using.

Read on →