<link rel="prefetch" href="/images/big.jpeg">

With the href being the target content and the rel attribute triggering the prefetching mechanism. Pretty simple. I've already implemented it here on my gallery pages.

One thing I would like to see, and this is hinted at on the above linked Mozilla FAQ page, is prefetching performed automatically on anchor (<a>) tags with rel attribute set appropriately. In my mind that would be any anchor with a rel attribute of next, but the prefetch value would be fine as well. Personally, if that were supported I wouldn't have any (or very little) work to do to take advantage of this feature and in a general sense it would build on what people are already doing using prev, next and toc rel attributes on gallery links.

*it was scrapped because I hated the idea of forcing bandwidth usage on people with metered accounts. Since this is a browser based mechanism, it should be relatively painless for people in that situation to control whether or not content is prefetched.

Admittedly, the vast majority of those visits have been to this site, so it's not as broad a sampling as I would like, but it's still and interesting number after just two weeks.

For reference here are the DrunkenFist.com numbers for the two weeks it's been out

As you can see Chrome is nipping close at Opera's heels. Can Safari be far behind? We'll see how it all plays out.

In case you were wondering… YES I do love the fact that Firefox browsers are the #1 browser of choice of DrunkenFist.com visitors.

What are other people seeing in terms of Chrome adoption?

Here's the code*:

function getElementsByClass(theClass,node) {
    var classElements = [];
    var i;
    if ( node == null ) {
    	node = document
    }
    if (node.getElementsByClassName) {
    	var tempCollection = node.getElementsByClassName(theClass);
        for (i = 0; i < tempCollection.length ; i++) {
    		classElements.push(tempCollection[i])
    	}
    }
    else {
    	var els = node.getElementsByTagName("*");
    	var elsLen = els.length;
    	var pattern = new RegExp("(^|\\s)"+theClass+"(\\s|$)");
    	for (i = 0; i < elsLen; i++) {
    		if ( pattern.test(els[i].className) ) {
    			classElements.push(els[i]);
    		}
    	}
    }
    return classElements;
};

The above code works as expected in Firefox 2, 3; IE 6,7,8, Opera 9.5 and Safari 2.

Interestingly it doesn't work in Safari 3.1. Safari supports the native getElementsByClassName, so one would expect it to work alongside Firefox 3 and Opera 9.5.

It does not.

Here's a sample. Click "start" and everything should go from blue to black (which means the class is removed from the LIs) and the numbers should read "10 0". The 10 is the length of the collection returned by my function when the test starts. The 0 refers to the length after the test has run it's course and the class has been removed.

Safari 3.1 looks like this:

So the count is 10, even though there are 0 instances of the class in the DOM:

This is the code I'm running:

function testSafari() {
    $("messages").innerHTML = getElementsByClass("sample").length;
    var samples = getElementsByClass("sample");
    for (i=0;i<samples.length;i++) {
	    removeClass(samples[i],"sample");
    }
    $("messages").innerHTML += "    "+getElementsByClass("sample").length;
}

I've approached the problem from a few different angles (not exhaustive) and taking a quick look at the WebKit source it seems to me that Safari might be incorrectly caching the results of the getElementsByClassName call. I haven't had the time I would like to test this to see what might be happening in specific, but that's what it feels like.

Anyone know more about the guts of WebKit? Am I onto something? Or is my nonexistent Apple dev knowledge showing?

For the webdev crowd, anyone else seen anything like this? Is it something stupid that I'm doing that I'm just not seeing (and therefore not actually a bug)?

That's always my first assumption, but the native method works in both Opera and Firefox so I'm more confident than normal that the issue isn't my fault.

*I used to have support for a specific tag. When rewriting it I thought "I never use the tag argument, I'm dropping it." Of course, as soon as I did that one of my co-workers used the tag argument in a script he was writing for a site we were working on. I'll be adding the tag option back in.

Also, this version relies on support for Array.push(). Our little library adds it in with this:

if(!Array.prototype.push) {
    function array_push() {
        for(var i=0;i<arguments.length;i++){
	        this[this.length]=arguments[i]
        };
        return this.length;
    }
    Array.prototype.push = array_push;
}

As you can see, while it's now third, Internet Explorer 6 is still hanging on with unfortunate tenacity. Which means we still have great pain to deal with when trying to develop cross-browser web sites in this rich, interactive era.

I also means there's demand for people like me who know how to handle the beast, so I guess I should look to that as a silver lining…

Still, die IE6 die.

Say no to IE 6! Our current campaign focuses on assisting users in upgrading their Internet Explorer 6 web browser. This campaign will result in former IE 6 users having a more enjoyable experience on the web while (hopefully) creating a less stressful and complicated environment for web developers by hastening the retirement of an outdated browser.

Say it loud!

I've been writing about the slow adoption rate for a while now and it's still a source of frustration. Over the past month this site has seen 9,078 visitors using IE6.* Which is precisely 9,078 too many.

Honestly? In some sense it's a positive number, as the overall percentage of users on IE6 is shrinking. It's still not shrinking fast enough, however, so sentiments like the above speak to me like a call from up on high.

Sure, my site (and really all of my sites) looks fine in IE6, but it's still a pain to have to support it, even if it's just the extra bytes I have to serve other browsers (in the form of conditional comments.) And really, being the stickler for good experiences that I am, I still have to test and bug-fix for IE6 whenever I add new features or styles. Supporting two version of IE is awful, especially when one is so much better than the other.

I won't even get started on the issues at work.

Okay, maybe a little.

While I've got a hip, upgrading crowd that visits this site, the people we build for at work are generally running old, locked down machines running whatever browser their IT department wants to support. Care to guess what browser that might be?

Yeah.

IE6.

*sob*

*compared to 32,372 using Firefox and 15,385 using Internet Explorer 7.