VulgarisOverIP

Scripting With jQuery or: How I Learned to Stop Worrying and Love the DOM

To understand my new found infatuation with jQuery, I’d like to begin with a story about the problem that led to this posting.

The :hover pseudo-selector is one of the most powerful tools when working with a CSS compliant browser. With it, you can create rollovers, menus and other visual tricks without resorting to the “messiness” of Javascript. Tiny pieces of interactive logic describing complicated visual states can be included as snippets of text that even your designer can understand and use. If only it were that easy.

Because of IE’s limits, an entire generation of web developers have learned to use anchors (’s) for everything from menu items to blocks of text. Clearly, these are not the applications this element was semantically design for. Up until version 7, Internet Explorer never allowed you (the highly competent web developer that you are!) to use :hover selectors for anything except anchors. Of course you could always just use javascript to manually attach effects to a particular element, but that seems ridiculous when you end up having to write dozens of lines of code just to get 4 list items (’s) to change classes on mouse over. A List Apart is a site that I look to for direction when simplifying a design, but even their solutions to this problem makes me cringe.

Me: Now that I’ve laid out the problem, can you guess the solution?

You: jQuery, of course!!!

Me: Nope, what the heck is jQuery? Anyways, I’m going to write a super awesome script that just plugs into any project, re-downloads all the CSS files using bleeding edge AJAX code, parses that CSS using only the tightest regular expresssions, and then shoves all those :hover’s down IE’s throat.

Here it is. I even had the temerity to name it “fixCSS” because I thought that a couple pages of Javascript code would unify every browser on the market and allow anyone to use use compliant CSS blissfully unaware that there was any sort of scripting on the site.

It works too, go ahead. Download it, add Prototype.js, put some :hover’s in your CSS, fire up IE in your favorite virtual machine (you aren’t running IE locally are you?!?!) and wait for the page to load. It just works.

But there’s a problem. If you created a simple test with one small CSS file and one small HTML file and ran it on your local development server you probably didn’t notice it. But if you are running on a busy server with multiple CSS files and another 100k of html and images, you are definately going to notice something is wrong with IE. For about 2-3 seconds nothing seems to work. You can move the mouse and click, but rollovers don’t work, clicking doesn’t work and hell, the mouse cursor doesn’t even change over links. Then suddenly, after a couple of seconds of violently swinging your mouse back and forth across the screen, menus start dropping down and you can safely navigate to another page. And when you do, guess what happens…

You see, before writing this script I forgot the cardinal rule of web programming: implementation doesn’t matter, speed does. Visitors to your site don’t care if your CSS is the pinnacle of seperation of presentation and content, they care if they care about using your site. And compared to loading for 2 seconds, loading for 5 seconds is an eternity.

I learned this the hard way after 1 day of visitors using this script. My site needed a rewrite, fast, and I thought it would be a good opportunity to put into use a very interesting library: jQuery.

I had come across jQuery when I began planning phase 2 of fixCSS: more selectors! I was going to fix >, , [], and any other symbol I could find on my keyboard that IE didn’t respond to in CSS files. By this time I realized that simple parsing of the CSS files wasn’t going to be powerful enough, I needed a CSS interpreter in Javascript. Prototype, another popular and powerful Javascript library, at the time had a function called $$(). In theory, you supply this function with a CSS selector and get back a nice array of elements. In practice, I supplied it with CSS selectors and got back hours of frustration.

I then began to scour the net for a single function that could do what I required. I don’t remember how I first came across jQuery, but I do remember the initially feelings I had when I wrote this:

$('ul .menu_item').hover(function() { $(this).addClass('hover'); }, function() { $(this).removeClass('hover'); })

If you’ve ever programmed anything in your life, you can guess what this does. Upon seeing code like this and thinking about the days I had wasted on fixCSS, I almost became depressed. I immediately deleted fixCSS.js (just to get you guys a copy I had to look through my old CVS repos) and Prototype, rewrote all my Javascript into a few small snippets of code and ended up cutting 50kb(!) from the average page I was working on.

It’s all so clear to me now. There’s no reason (and no possible way) to implement a real-time CSS file interpreter for web sites. The ability to decode CSS selectors in Javascript provides a common language for those designing a site and those developing it. By incorporating style selectors with powerfully augmented DOM elements and lot’s of functions mapping onto arrays, jQuery has boiled down site scripting to it’s core: select some nodes, select the event you want to capture (optional!) and do some logic. I’ve learned that it’s alright to use Javascript to make up for the inadequecies of Microsoft, Apple and all those other bastards. Learn to forget about which browser you’re using, try jQuery on your next site and you’ll see that scripting can be fun again.

[tags]jquery, hover, selectors, css, javascript, dom, prototype[/tags]

Comments