CSS3 mixins for SASS

The Compass project provides a ton of useful mixins for SASS, but over the course of many projects I’ve created a streamlined set that’s more useful for my day-to-day development.

My mixins prefix where necessary and I try to provide smart defaults. The naming convention is descriptive and not just a flattened reproduction of the CSS3 properties being used.

“Next Unread Message” Script for Apple Mail

One thing that’s always bugged me about Apple’s Mail.app is the lack of a quick shortcut to your next unread message, irrespective of which mailbox it is in. Luckily, it was fairly easy to whip up a quick little script which does just that. Note that the script assumes your mail is sorted with the newest messages at the bottom — otherwise, you’ll need to edit line 7, replacing “last message” with “first message”.

Add a keyboard shortcut with your favourite tool, like FastScripts or Quicksilver.

Cappuccino’s FlickrDemo in 45 lines of jQuery

When I first saw 280 North’s “280 Slides” application, I have to admit I was very impressed. They built a truly native-feeling (well, if you’re on a Mac) tool on the standard web platform. Not an easy feat, and clearly some big brains operating on the problem.

But the more I read about their toolkit (Objective-J), the more unsettled I felt. It’s the same feeling I get when I see tools like Flex. These are some seriously complicated development environments, meant to abstract away to the fundamental building blocks of the web.

When 280 North released their Objective-J toolkit a few days ago, called Cappuccino, I poured through their documentation and demos to get my head around what they had built. And it’s very impressive. But as a jQuery addict, I didn’t like their dismissal of it as at tool for making small adjustments to a web page. I feel that you can build a full-fledged web application in jQuery just as simply — or simpler — by embracing HTML/CSS as a layout engine, and JavaScript as a scripting language.

So I tackled re-implementing their FlickDemo application (several hundred lines of Objective-J) using jQuery and jQuery UI. It took about 3 hours to build, and ended up being about 45 lines of code (plus the frameworks, of course), and just under 200 lines of CSS declarations.

What I didn’t do: I didn’t bother hacking the CSS to work in Internet Explorer. It’s not that it couldn’t be done — jQuery supports it just fine — I’m just lazy. So you’ll need a modern WebKit or Gecko browser to see the demo. I also didn’t implement the drop shadows that Cappuccino uses on their images.

Also, the jQuery version doesn’t take over all you keyboard shortcuts, so you can still navigate around in your browser.

Original Cappuccino version

My jQuery version

Download the source here: flickrDemo-jQuery.zip

Update: Due to popular demand, I’ve changed the behavior of the slider so the image size updates in realtime. Total change: one word.

Update 2: Alexander Simmerl was nice enough to provide an upgrade to the image loading, bulking up the code by a few lines but greatly improving the load animation. In the comments, dak contributed a 2-line CSS fix for the inline-block layout problems in FF2 and IE7, which I’ve also merged.

I think this is as far as I’ll take the demo. Ultimately, it’s not that compelling of an application (but it does make a good demo). To respond to some of the criticism I’ve read, my point was not to argue that jQuery was a drop-in replacement for Cappuccino. Clearly there’s a ton of nuances to the Cappuccino runtime that would need to be carefully reimplemented if we wanted a 100% identical demo. My point is that it’s quite simple to do web application development in jQuery, and something as heavy as Cappuccino is not the only option (and in many cases, probably not the best option). I see Cappuccino as a kind of AIR-in-reverse (native apps that run in a web browser!) and possibly an interesting technology path for coders that are already familiar with Cocoa but don’t have experience with the nuances of direct web development. One thing I’m sure of is HTML/CSS/JavaScript are not going anywhere… they may be complimented by frameworks like Cappuccino, but the core will remain.

We don’t need IE8′s “Doctype 2.0″, we need effective browser deprication

A few days ago, the web development community exploded into an uproar concerning the IE team’s plan to introduce a new method of triggering standards compliance mode in Internet Explorer 8. Web developers, with justifiable but thinly veiled vitriol, ripped into Microsoft and the Web Standards Project for going along with this scheme.

In essence, what the IE team wants is web developers to “opt-in” to new renderer features using a custom meta tag or HTTP header. Pages will then be frozen at that renderer, ensuring they remain consistently rendered from now until the end of time (or at least, until Microsoft stops supporting that rendering model or breaks it accidentally). We went down this path once before, using the Doctype declaration to differentiate between “quirks” mode and “standards” mode. IE7 is, unfortunately, also quirky in standards mode, so apparently we need a new “super-standards” mode for the next version (and so forth).

From the perspective of the IE team, this solution makes sense. They can effectively freeze HTML rendering at today’s IE7 baseline and proceed with enhanced features in later releases. Maybe I’m looking at this the wrong way, but I never considered HTML content to perfect screenshots that should remain immutable. Well designed HTML is flexible — it can be rendered by a desktop browser, or stripped to it’s barest essentials by a mobile parser. (Note that I’m drawing a clear line between web content and web applications — web apps are by their very nature a snapshot of the present). The IE team should be encouraged to fix their mistakes at the expense of breaking badly developed content, just as users should be encouraged to update their rendering engines as frequently as possible. Notice that the IE team is the only browser developer that seems to have this problem.

As a web designer and developer, apparently I’m supposed to help Microsoft maintain their dominance in the web browser market by tagging my pages for their benefit. But what do I get out of the bargain?

Let’s assume for a moment that IE8 has been released with a spectacular new rendering engine, on par with Firefox or Safari or Opera in terms of “write once, render anywhere”. Let’s also assume I have a pretty good idea of what my target audience’s browser technology will be: 50% “IE8 compatible” (meaning IE8/FF/Safari etc), 30% IE7, and 20% IE6. None of these markets are small enough to ignore or deliver reduced functionality to. I would still need to optimize for three different version of Internet Explorer. IE7 doesn’t go away, and neither does IE6. I can’t just freeze the renderer at the IE7 level — I want to use all those fancy new features in IE8 that have been available in alternate browsers for years now.

So where does this leave me, the web developer? Still coding for multiple releases of IE. In fact, the problem gets worse as Microsoft accelerates it’s release schedule — people simply don’t update quickly enough. IE6 is still estimated to have a 35% market share — over a year after IE7′s release. How do we solve the problem of supporting multiple renderers?

Simple. We deprecate IE6. We no longer support it. And we provide a clear, direct upgrade path that involves little to no effort on the part of the user. Maybe this involves just swapping out the rendering engine, leaving the browser’s UI intact (to minimize the impact on the user’s day-to-day experience interacting with their browser). I’m certain part of the resistance to upgrading to IE7 today is the horrendous overhaul to the UI that occurred between versions.

Apple doesn’t seem to have any problems keeping it’s Safari users (or iTunes users) on the latest release through an effective software update system. Firefox also has a fairly effective system, although it could be improved. But web developers don’t complain about supporting multiple, ancient versions of those browsers because the system, and the users, are proactive about updates.

We need to get over the idea of preserving out-of-date content as a snapshot of the day it was released. We need to stop worrying about breaking 5-year-old browsers and just get on with it.

Update: After further reflection, there is another (possibly better) approach Microsoft could take. They could include the IE6 and IE7 rendering engines in each new update, and provide a user-accessible toggle for enabling it on specific sites. Using the info bar, much in the same way they do when blocking popups or enabling ActiveX downloads, a message could be displayed along the lines of “This page may not be compatible with the Internet Explorer 8 display system. Would you like to switch to Internet Explorer 6 compatibility mode for this site?” IE would remember the setting and use it on subsequent visits. The compatibility message could be triggered by detecting known CSS hacks, or even based on the Last-Modified date of the document.