Assembling the web designer’s toolkit

Web designers need a lot of tools at their disposal. Mostly this comes in the form of commercial software. If you don’t own the full Adobe Creative Suite, you at least have Photoshop (or, if you’re a FOSS contrarian, GIMP). If you’re on a Mac, you probably have BBEdit (or its free sibling, TextWrangler) installed, and if you’re on Windows… well… I don’t know. Does anyone who takes themselves seriously as a designer use Windows? I’m sure we’ll hear from them in the comment section.

But what I’m talking about here is not the commercial software applications you have installed on your desktop. I’m talking about the free libraries you probably need these days to get a “Web 2.0” site up and running.

I’ve been finding myself lately starting each new project by cobbling together the same set of these libraries, so this morning I decided to save myself some time on my next project by putting together a template set with all of them in place. Once I’ve had time to review all of the requisite licenses, I may post the complete package in a zip file here, but for now, here are some pointers to get you started.


Where better to start than with this easy-to-use, infinitely extensible JavaScript library? I can’t imagine working without jQuery anymore. It makes just about everything JavaScript-related several orders of magnitude easier to work with. And then of course there are a handful of plug-ins I like to bring along for the ride: color, dimensions, em, hoverIntent, lightbox, mousewheel and jScrollPane. (Actually, several of those are required just for jScrollPane, a complex and tricky-to-implement plugin, but if you need custom scrollbars, it’s worth it.)

Lightbox for jQuery

I especially want to call attention to Lightbox for jQuery, based on the original Lightbox for Scriptaculous (see below). It’s a great way to add some nice polish to your site. Whenever a user clicks on a thumbnail to see a larger version of an image, you no longer need to subject them to an ugly and confusing plain browser window with the image in the upper left corner, or trigger a new pop-up window to appear. Lightbox uses CSS and JavaScript to elegantly apply a translucent mask over the existing page and present the image in a centered layer hovering over the rest of the page, in the same browser window. Slick!


On the other side of the JavaScript library fence, we have Scriptaculous, built upon prototype.js. It’s not quite as slick or as powerful as jQuery, but it handles AJAX without additional plugins. Honestly, I haven’t tried much AJAX with jQuery, but since CakePHP‘s built-in AJAX helper relies on Scriptaculous, I’ll probably still have a place for it, for a while. The snag is that jQuery and Scriptaculous, with their default settings, don’t play nicely; they both want to use the $ variable for themselves. But jQuery’s noConflict() method makes it easy to get these two powerhouse libraries to get along.


This is my least favorite of the tools described here, for two reasons: 1) it’s essentially just a patch for Internet Explorer without adding any new functionality for general use, and 2) it reminds me that Internet Explorer exists.

That said, it’s indispensable. The issue here is simple: IE6 doesn’t support a lot of “modern” features that other browsers do, and that are becoming increasingly essential to how the Web works, but unfortunately, IE6 is still one of the two most-used browsers in the world (the other being IE7). Firefox is growing rapidly in popularity; Safari is ubiquitous among Mac users; and the Web is increasingly experienced via mobile devices, but for now, IE is still king of the hill, and a large percentage of IE users can’t, won’t, or don’t even realize they can upgrade beyond version 6.

IE6 can be taught new tricks, however, and that’s the purpose of IE7.js. It’s a JavaScript library that “teaches” IE6 to behave more like IE7, fixing some common and infuriating CSS bugs, adding support for alpha channel transparency in PNG images, and various other “magic” that pretty much all just takes place seamlessly, behind the scenes. Just call this library and let it do its stuff.


If you’re using Flash at all, it’s helpful to bring along SWFObject, another JavaScript library whose sole function is to relieve the attendant headaches of working with <object> and <embed> tags and the suckitude of Internet Explorer browser inconsistencies.


In the past, whenever web designers needed text to appear in custom fonts (that is, any fonts that are not already installed on the user’s computer), there was only one option: make an image out of it. Maintenance nightmare. Enter sIFR, a JavaScript-and-Flash-based solution. You’ll still need a copy of Adobe Flash (the full application, not the browser plug-in) to make it work, but the end result is your font encapsulated in a SWF file, and some very clean JavaScript that seamlessly swaps your custom font in place of regular, plain vanilla HTML, and degrades gracefully to a standard font if the user is lacking either JavaScript or the Flash plug-in. And it’s fully semantic and validating.

The only downside of sIFR is that finding the latest version is a bit of a mess. But here’s a good place to start.


And finally we come to TinyMCE. At last we have a decent solution to the dilemma of allowing users who probably don’t know HTML to enter styled content on your site. It’s not without problems, especially where pasting from Microsoft Word is involved, but TinyMCE is a great WYSIWYG solution, a word processor in a browser window.

Web 2.0 — opening up a whole new world of Internet Explorer quirks!

Just when I needed it least, Internet Explorer has thrown me another curveball.

I’m hard at work trying to seem like less of a 20th Century web dinosaur by acquiring new skills with these techniques that are loosely lumped together into what some call “Web 2.0.” Key among these is an approach called AJAX (Asynchronous JavaScript and XML). Fun stuff. I’ve been working for the past several days on an interactive registration form for a site at work, using AJAX. Of course, as usual, I’m plugging away in Safari and Firefox, but eventually I decided to check out how things are looking in Internet Explorer.

[When I figure out an emoticon that represents my head exploding, I’ll insert it here.]

IE is consistently barfing on what it claims is a syntax error that I eventually tracked down to the evalScripts function in prototype.js. Well, at least it’s not my own code that’s making it crap out this time. Or is it? With IE you never can tell. Maybe evalScripts is buggy (even though I can find no evidence to that effect) or maybe it’s just the code in my script that’s being thrown at it. Whatever the case, once again all forward progress has come to a grinding halt while I scour the Internet fruitlessly for a solution.

Although this turned out not to be a solution to my problem, I just have to refer you to this developer’s blog entry on a typical IE workaround. Yes, I tried this, even though I was almost positive his problem was completely unrelated to my own (which was the case). Nevertheless, when a problem does arise in IE, the most likely eventual result of one or more days’ worth of sleuthing is the resigned acceptance of such hokey code bloat, rather than anything even remotely satisfying (or even logical).

There you have it. As for my own problem using prototype.js with IE, I did find a solution. Yes, it was my code, and it was something I had seen previously that was pretty much staring me in the face, if I had just bothered to heed Thomas Fuchs’s sage advice.

It all comes down to standard practice for wrapping <script> tags in HTML. I still have the habit of doing it this way:


The funny thing about that is that I know it’s completely pointless these days. It’s done so that browsers that don’t support JavaScript don’t inadvertently display the JavaScript code in the web page. But every browser has supported JavaScript since about 1997, so it’s pretty ridiculous to keep doing that. Especially given that, the way the sites I’m working on are so utterly dependent upon JavaScript, you’d never even get to the page in question without it.

However, with XMLHttpRequest (which is at the heart of AJAX), and just the increasing complexity of JavaScript in general, it’s become necessary to wrap script code in a new tag to ensure that browsers handle the code properly. To wit:

// <![CDATA[
// ]]>

Just as Thomas Fuchs said. And just as has been lingering in the back of my mind for the past several weeks, since I first discovered his wonderful tool based on prototype.js, Scriptaculous. I’ve learned my lesson.