// Create a medium size array, at least 100 items
var obj = [];
for(var j=0, k=150; j<k; j++) {
    // the value here doesn't matter.
    obj.push('ABCD'+j);
}
 
// Sort the array alphabetically.
obj.sort(function(m,p){
    m=(''+m).toLowerCase();
    p=(''+p).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

The obj Array should now be sorted, in alphabetical order based on value. BUT, in our best friend Internet Explorer, a Number Expected error may be the result. Don’t be fooled if your test array behaves correctly, it only happens intermittently for arrays of varying size!

So, I whipped up a quick test to check the damage. Iterating over array sizes from 1 to 150, running the Array sort algorithm. The following failures resulted:

* Failures may vary to the specifications of the test machine.

Of course, the Number Expected error is going to result whenever your code doesn’t return a number inside of the function callback. But the problem here is something deeper than simple application code failure. The problem is in JScript itself. Any modification to the sort arguments may result in the Number Expected error.

    m=(''+m).toLowerCase(); // modifies the argument m and is unreliable.

This problem will manifest itself more frequently if you use the Google Closure Compiler, which restructures JavaScript to reuse argument variables if possible, probably to save the 4 character penalty of a “var ” declaration.

Normally, reusing argument variables is a safe practice for primitives, since they are passed by value and not by reference, as is the case in this Array sort example ¹. So, what exactly is going on here? One commenter at the Google Closure Compiler bug seems to think that the actual array values are being passed by reference instead of by value. I’m not completely convinced that’s the case.

The Fix

Don’t reuse the argument variables inside of an Array sort function.

// Changing the above example
obj.sort(function(m1,p1){
    var m=(''+m1).toLowerCase(),
        p=(''+p1).toLowerCase();
 
    if(m > p) return 1;
    if(m < p) return -1;
    return 0;
});

Check the source code of the demo file to see the different methods of modifying the arguments that I attempted.

1. If you want to learn more about passing by value or reference, Jonathan Snook has a nice explanation.

Internet Explorer can’t make you do anything, it can only make you wish you hadn’t.

Now, upon discovering myself a newly minted Mac OS convert from the hugely popular World of Windows, I quickly discovered that the application menus (File, Edit, etc) were one of the glaring differences I’d have to adjust to. Mac OS had all menus separated from the application window, all the way at the top of the screen. Coming from the Windows environment, this seemed unintuitive. But after reading more about Fitts’s Law, I discovered the reasoning: the edges of the screen are treated as an infinite height or width! Which is just a way of modifying the Fitts’s Law to say: the easiest things to click on are at the edges of the screen. That’s why the close icon or the Start Menu is so easy to access on Windows, and why the Application Menu is at the top of the screen in Mac OS.

We know about Fitts’s Law, but why aren’t we applying it to our web applications? Why aren’t we using the power of infinite height/width to help out on our designs? It seems like this crucial usability law has been overlooked on the web, and without good reason. Let’s look at a few applications that get it wrong (of course, in my humble opinion).

All of these screenshots were taken from 100% width designs, with no real reason not to incorporate the ideas behind Fitts’s Law into the menuing system. At first glance when I brought up Google Reader, I was excited. The hover behavior appeared when the mouse cursor was positioned at the very far left of the screen, but was disappointed to discover that the although the hover background color had changed, the entire hover target was not clickable.

Naturally, I decided to make a test of my own, to test which web browsers allowed Fitts’s Law Menus. The test case encompassed both left and bottom aligned menus, for completeness. A top menu was excluded, given that the top of the screen is reserved for browser chrome or application menuing. A right menu was also excluded as the right portion of the screen is reserved for the page scrollbar (which is the easiest scrollbar to manipulate with your mouse, per the same rules).

Also, on the Mac OS 10.6 and Windows XP operating systems, a Fitts’s Law Menu at the bottom of the screen is not possible, given that the Dock and Taskbar in these operating systems occupy at least a 4 pixel trough of the bottom-most space on the monitor, even as a hover target in “auto-hide” mode. Everyone is fighting over these crucial and very useful edge pixels.

To test whether or not this behavior is working correctly, maximize your browser window and move the cursor as far left on the screen as possible, but still over the menu. If the links are still clickable, congratulations, your browser works!

View the Demo / Test Page for the Fitts’s Law Menu

Compatibility Table

The full screen mode of each individual browser was considered outside the scope of this study.

Conclusion

We should stand on the shoulders of giants and reuse the usability studies already completed on software that has gone before us. The left side of the browser window is the best place to utilize Fitts’s Law, and we should move our left-aligned menus on fluid width designs to occupy the space flush with the window’s edge to increase the speed at which those menus will be accessible by users. Having an infinite width menu is a big click target to hit.

Generally when exploring a development opportunity, I tend to prioritize my adventures towards things that are supported in Internet Explorer first. This often has the biggest cross-browser payoff, since the other browser vendors tend to have a quicker draw than the Microsoft Team. However, surprisingly enough, this writing-mode study proved the opposite to be true. It seems very interesting that Microsoft has decided to implement a portion of the CSS 3 specification, given its general stance of moving slower than an iceberg to avoid “breaking the web.” But I, for one, welcome our new choose-your-own-adventure standards loving overlords.

As far as my tests go, the only browser to support the writing-mode property at all is Internet Explorer, which was very surprising. At it’s heart, though, writing-mode is just shorthand for two other properties: direction and block-progression. Luckily, Firefox, Safari, Chrome and IE back through at least version 6 support the direction property and have proprietary options for rotation, which allows for emulation of a few of the unsupported writing-mode’s, but not all of them. The missing piece of writing-mode emulation belongs to the block-progression property, which isn’t supported by anyone, and would allow elements to flow reverse vertically (start at the bottom of a block and flow upwards).

It’s important to note that while IE8 has really set the bar for implementation here and has chosen to support writing-mode: lr-bt and writing-mode: rl-bt, they aren’t used to display any known language text. They’re just included for completeness, and aren’t a part of the W3C CSS 3 Text Module specification.

View the Demo / Test Page

Compatibility Table

CSS Code for Emulation

// Default

direction: rtl;

// Not possible using W3C spec

// Not possible using W3C spec

// Not possible using W3C spec

-webkit-transform: rotate(90deg);
-moz-transform: rotate(90deg);
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

// Not possible using W3C spec

direction: rtl;
-webkit-transform: rotate(90deg);
-moz-transform: rotate(90deg);
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);

Conclusion

Given that 4 of the 6 known writing modes are available or available through CSS emulation means we’re in pretty good shape on the internationalization front. Consulting the Microsoft provided table for common use cases, we’re only in trouble when trying to use the “Mongolian script writing system” and an “Arabic script block quote embedded in Mongolian script document.”

In some far fetched fantasy-world legacy application where a page may use tables for layout, I could see an application team possibly using the direction property to redistribute the tables for a print stylesheet. But that certainly wouldn’t be a common use case, since using CSS for layouts is going to give you much more flexibility in that regard. If you can think of any other off the wall uses for writing-mode or direction, I’d love to hear them!

Related

• Very complete article on CSS 3 writing-mode, including some direction properties that don’t exist in the specification (like ttb, ltr-ttb, and ltr-btt)
• Bugzilla Bug for writing-mode in Firefox
• As of the time of this writing, I was unable to find any results for writing-mode on the Webkit bug tracker.

It would seem that perfection is attained not when no more can be added, but when no more can be removed.

While most would argue that the principles espoused in the above quote might also be applied to the quote itself, it would serve us better to consider how we can attempt perfection in our User Interface designs instead.

The most complete litany of reasons why you should spend your page weight on more useful bytes has been compiled by Jukka Korpela, although he seems to both confirm that they are harmful and still use them on his site.

The rules of engagement I find useful when dealing with the ill-fated “Back to Top” or its ugly stepsister “Top of Page” link are as follows:

1. Delete the link.

Really, you don’t need the link. It’s a sacred cow remnant of a time when people believed that all content needed to be positioned above the page fold.

Guess what? People know how to scroll! They know how to scroll down, they know how to scroll up. Considering this prerequisite has been met, it becomes very apparent that the “Back to Top” link shares an unnecessary overlap in functionality with the scrollbar and is thus, unnecessary itself.

If you have an incredibly long page with a full set of “Table of Contents” links, it would be better to position your table of contents fixed to the viewport, so as to make it always available to the user. If the Table of Contents is always available, the user will never have to click a link as a shortcut to find it.

While not a usability epidemic, the “Back to Top” link is still widely used. Instant Shift and Smashing Magazine both have articles with hundreds of examples of sites with these links.

Don’t agree? If you’re stubborn as hell and hate simplicity, you’re going to keep the link on your page no matter what reasons are presented. In that case, at the very least follow these two guidelines:

1. Use progressive enhancement:

   <a href="#" id="back-to-top">Back to Top</a>

   // jQuery Prerequisite
   $('#back-to-top').click(function() {
       window.scrollTo(0,0);
    
       // don't change the hash if not needed
       return false;
   });

2. Hide the link if the page doesn’t have a scrollbar. If no scrollbar exists, the user will always be “at the top.”

   // Continuing with Previous Example
   $(function() {
       $('#back-to-top').hide();
   });
    
   // If the page scrolls, we know there is a scrollbar.
   $(window).scroll(function() {
       $('#back-to-top').show();
   });
    
   // For completeness, you may also want to
   //   add logic to the "resize" event.

Really though, just delete the link.

Take a look at the Dingbats section on fontsquirrel to get your brain going in the same direction.

Webdings is a symbol font designed in 1997 as a response to the need of Web designers for a fast and easy method of incorporating graphics in their pages.
…

Webdings is ideal for enriching the appearance of a Web page. Because it’s a font, it can be installed on the user’s system, (or embedded in the document itself) is fully scaleable [sic] and quick to render. It’s a perfect way of including graphics on your site without making users wait for lots of graphic files to download.

– Source Microsoft Typography

Microsoft was onto something here, and there is a nice parallel that can be drawn between the font and a CSS sprite: namely that multiple images are stored under the guise of a single HTTP request. So, why not create our own font and use it as a CSS sprite? Each character in the font (glyph) will be a single image in the sprite.

Why is this awesome?

• We can change the color of our font using nothing but CSS color. This is a big one. We don’t have to have separate images for hover states! And if we want to change the color scheme, there are no new images to generate and we don’t have to make any changes to the font to do so.
• Don’t have to monkey around with difficult to maintain CSS positioning code.
• Fonts scale, graphics don’t. Zooming in on a graphic will result in a pixelated image, but fonts will be smooth like a 6 blade razor shave. Try zooming on the demo file below.

Why is this not awesome?

• Font glyphs can only contain one color.
• May experience the Flash of unstyled text (FOUT) while the font is loading.
• Extra markup required for IE6 and IE7. While @font-face is supported in all non-extinct versions of IE, each @font-face sprite requires a corresponding text character on the screen. For instance, <span style="font-family: MyCustomFont;">A</span>, the A is required to display the @font-face Sprite stored under the A glyph.
  
  Luckily, in most browsers we can inject a character using CSS :after/:before and the content property. Unfortunately, this is not supported in IE6 or IE7. I haven’t investigated whether or not this might be solved using other means (CSS expressions) yet.
• Safari asks for permission to use the font with a scary popup box, which I assume is a security precaution gleaned from the Windows Vista playbook.

Demo

The following jQuery UI Icons are currently used in jQuery UI and are stored in one big CSS sprite.

It was pretty trivial to create a font with a subset of the jQuery UI icons (only the first 20, just a proof of concept here) using the wonderful FontStruct utility. Then, I took the TTF generated by FontStruct and plugged it into the completely lovely FontSquirrel @font-face Kit Generator. That gave me everything I needed for a fully cross-browser test.

• View the Demo

Let me know what you think!

Read more about @font-face support from Paul Irish.

We must be resilient to resist the transformation from development pragmatism to user abandonment, especially considering a developer’s trend of being insulated with the latest equipment. We use the newest hardware and download the most sophisticated browser software because we want the best experiences. We stack the cards in our favor. The difficulty lies with the populace that want a good experience (they can tell a fast site from a slow site), but they don’t want to buy new equipment or install a better browser. So the question has become: Where do you place your chips on the spectrum balancing modern hardware/software and the user experience?

As web developers, it has become increasingly easy to become disenfranchised with the lay majority’s computing environment. I’ve witnessed this personally after purchasing my first Apple computer, a device curiously immune to the plague of IE 6/7 (8 as well, but I would hesitate to label it as a plague, more like a normal run of the mill flesh eating virus). It’s an interesting phenomenon, being cutoff from the Windows environment (save virtualization) during development. It’s delightfully tempting to declare damnation upon the plague ridden Internet Explorer Zombies, and develop your web presence to standards alone, allowing less focus on the harshest development environment imaginable and more on actual problem solving.

When developers engage in quasi-web development, perhaps in the form of an iPhone specific web application or an Adobe AIR desktop application, it fosters similar feelings. The work shares many languages and technologies with real (wide-open) web development, but is targeted towards a single web browser. This benefits of this sort of tunnel vision device targeting must be carefully weighed against the penalties you’re paying in narrowed default-install client compatibility. At that point, it’s just friends with benefits.

Google Wave, in fact, requires the use of Safari, Firefox, Chrome, or the Google Chrome Frame plugin (which doesn’t count as actual browser support). As of the time this article was written, as many as 64% of all users (source) are met with the above screen when trying to access Google Wave. Let’s be clear: Ease of development is not an excuse to abandon users. Whatever happened to Device Independence?

Not surprisingly, Google Wave’s stand against Internet Explorer has not started a trend. Instead of all out war, the community at large has decided that subtlety is what’s needed to win this fight. Let’s hold back the sexual healing of rounded corners, even though perhaps users will call our design harsh or cold. Let’s give them plain buttons instead of nice three dimensional buttons with text and box shadows, even though they may be less actionable.

Let’s make it easier on ourselves at the expense of the user experience of The Zombie Majority. We make this sacrifice because we assume that Zombies won’t be able to tell the difference between eating a big juicy Einstein brain and a smaller but nonetheless still tasty brush clearing George W. And you know what, I think we’re right.

Updated to include a few more thoughts on Adobe AIR and the iPhone.

Big Enterprise is traditionally known for creating development environments that foster a “get it done” mentality, often rewarding results over correctness (mileage, of course, may vary).

My company uses IE6, and the application works in IE6, so it’s done!

This little quagmire is amplified by the fact that when using Open Web technology, there are many ways to get things done, and most of them are incorrect. But those mistakes don’t manifest themselves until the project is in the hands of the end user, whom we often punish for our oversight.

But there is hope. Using the power of web standards and Open Web best practices, we can achieve something panoramically, not microscopically, beautiful.

The secret sauce of building for the Web isn’t its distribution model, in which updates are managed on the web server without the need to update software on the client (although the Anti-IE6 vigilantes would tell you differently). It most certainly isn’t development efficiency, as most people new to the game will so readily inform you of. Cross browser quirks due to non-standard browser implementations of CSS and JavaScript, or vague standards specifications have seen to that.

When I was writing Visual Basic, I got my job done so much quicker and easier!

The power of the Open Web is Device Independence.

Visitors to our sites shouldn’t be met with warnings about what device they’ve chosen to use.

This site viewable only in IE7+, Firefox, Chrome, or Safari, and at minimum 1024×768 resolution.

This site requires Flash or Silverlight

I realize that this is a controversial stance, especially given that most sites are dropping support for IE6, and more are relying on Flash and Silverlight plugins. Architect applications to your client device usage statistics, and don’t let your tools shape the statistics for you. Using techniques like progressive enhancement, we can ensure that our sites degrade gracefully to the capabilities of the client device. At it’s truest form, this is basic accessibility. But, Device Independence might be a more accurate term, since accessibility is unfortunately an overloaded term scoped solely with devices tied to disabilities (screen readers, for example). While screen readers are a very important piece, there is a bigger picture.

When the iPhone came out, there was an uproar because it didn’t support Flash, for battery life and other reasons. But the uproar was from developers who had designed applications specifically for Flash! Would you say that those Flash applications were designed with device independence in mind? YouTube got around this by encoding their videos in MP4 format, which arguably has a higher device independence rating than the Flash format.

Keep in mind that we’re not attempting to handle every permutation of end user browser settings, since most don’t change the defaults. Instead we are trying to scoop up the largest base of supported devices with the least amount of effort! Who cares if an end user disabled JavaScript in their preferences? I’m more worried about the mobile browser that doesn’t even support JavaScript at all. But when you use Open Web properly, you get support for both!

Output Device Independence

• Full Web Browsers: Does your site work in Opera? Don’t worry about pixel perfection, that’s something completely different — does it work?
• Web Browsers on Mobiles
• Search Engine Spiders and other Screen Scrapers
• Screen Readers
• Printers: Ever had to make an entirely separate page for print-friendly version of your application? Flash/Silverlight do not print well
• Televisions: Xbox 360, Wii, and Other Media Center Devices
• Projectors
• and more…

Take a look at the CSS specification for media types. The standards are there! Support for CSS media types isn’t fool proof by any means, but the end goal is clearly visible.

Input Device Independence

But I’m not just talking about output device independence either. User interfaces should be adaptable to different input devices as well.

• Mouse
• Keyboard (often overlooked in web applications)
• Touch Screens (Single and Multi-touch)
• Voice, Motion Capture, and Facial Recognition (the standards and technology aren’t quite there yet, but progress is being made)
• and more…

The world is developing the Open Web, and it isn’t limited by a single company’s goals and timelines. At times, Open Web may seem like it’s a very slow moving glacier headed our way, but what else can you do but laugh when companies try to power their Titanic right through it?

Article originally inspired by Yahoo’s Graded Browser Support.

As of jQuery 1.3.2, adding multiple HTML classes to an element using jQuery’s addClass method will add them one at a time, modifying the className property of an element for each class.

$('#myElement').addClass('myFirstClass mySecondClass');

Here’s the original code inside of jQuery 1.3.2. Note how the classNames string is split, and elem.className is changed for each split entry.

add: function( elem, classNames ) {
    jQuery.each((classNames || "").split(/\s+/), function(i, className){
        if ( elem.nodeType == 1 && !jQuery.className.has( elem.className, className ) )
            elem.className += (elem.className ? " " : "") + className;
        });
    },
// ...

This may cause longer than needed delays, as reflow may occur after every class is added individually. If absolutely necessary, you can always fall back to modifying the className yourself, like so:

$('#myElement').each(function()
{
   this.className += ' myFirstClass mySecondClass';
});

Most likely, this isn’t a tip that will be needed, but it is useful to be aware of.

This morning I went back to the same URL to find a site that was no longer using the full page Flex application I had been expecting. Instead it was now using native Open Web technology.

Naturally, my first assumption was that I had hallucinated the original research. But as it turns out, I wasn’t the only one that noticed the Flex application. This blogger complained about the accessibility of a full page Flash/Flex store. Another blogger had a similar complaint.

I have no idea how long the Flash/Flex Adobe store experiment went on before they changed it back. I’m just glad I’m not crazy.

Update: Turns out they are using a whitelist/blacklist of user agents to decide whether or not to show the Flex store. The original entry point above is incorrect, and shouldn’t have the html subdirectory. If you go to the site in Chrome, it will redirect you to the HTML version. My apologies, Adobe, although I do think the HTML version is much more accessible.

When developing on the front end, it’s easy to prioritize correctness over performance. Performance is the step child that gets lost while you’re pulling your hair out worrying about cross browser compatibility. It’s very important to regularly benchmark your JavaScript code, using a profiler or some form of benchmarking code paired with a cross browser logging utility (see Firebug Lite, YUI Logger, or log4javascript).

Event delegation is a great way to program for performance. The live jQuery method was a great addition to the jQuery core, it makes event delegation really easy (see also the closest method). Unfortunately, it isn’t quite what I expected.

For example, say you have a page containing approximately 500 custom tooltip components on it (not typical, but stick with me, this is to prove a point). How might one go about adding a simple live event to activate each tooltip when the user hovers over it?

$('span.myTooltip').live('mouseover', function(event) {
    // activate tooltip
});

See the problem? jQuery will actually run the selector on the document, resulting in unnecessary overhead. jQuery is only assigning a single event handler to top level of the document, why does it need to know what nodes it will be binding to before assigning the callback?

What can we do? Let’s create a jQuery function, instead of a method, so it won’t query the document. Try this on for size:

$.live = function(selector, type, fn)
{
    var r = $([]);
    r.selector = selector;
    if(type && fn) {
        r.live(type, fn);
    }
    return r;
};

Usage

// Single event type
$.live('span.myTooltip', 'mouseover', function(event) {
    // activate tooltip
});
 
// Multiple event types (you can call the jQuery live method on the return value from the function)
$.live('span.myTooltip')
    .live('mouseover', function(event) {
        // activate tooltip
    })
    .live('mouseout', function(event) {
        // deactivate tooltip
    });

Also, as a side note, keep in mind that jQuery live doesn’t support space separated events, like bind does.

// Will not work.
$('span.myTooltip').live('mouseover mouseout', function() {});

Have fun!

Hit Options, then the Clock Format tab to change to Unix Time. Enjoy!

So, some sites have gone two ways, allowing OpenID, but also a proprietary registration system. This too, is problematic. It would seem that given a choice, the John Doe the Plumber style user will choose a proprietary account over the confusing user experience presented to them through OpenID.

But the annoyance doesn’t just lie with account registration for web applications. Typing your personal information on every blog you comment at is also repetitive and unnecessary. Some sites even require account registration for something so minor and transient as a blog comment.

Unfortunately, for the time being, it looks like registration forms are here to stay. So, what can we do to make those registration forms more usable, more efficient, and ultimately downright friendly? I know that you’re ahead of me on this one: Let’s auto-complete information for the user.

Please keep in mind that this power can be used for both good and evil. Essentially what we’re discussing here is data mining available information from various social networking sites on the internet, trying to glean personal information about an end user that has volunteered a piece of their data already. What can we get from what we already have?

Once a user has typed in their e-mail address, we can:

• Retrieve Twitter profile information (example shown on Chris Heilmann’s blog):
  • Full Name
  • Short Personal Description
  • Location
  • Web site URL
  • Time Zone
  • Favorite Colors (used on their profile)
• Retrieve an avatar if they’ve registered for the Gravatar web service (See my earlier post discussing this).
• Get their upcoming calendar events from a public Google Calendar. (Perhaps not as useful for autocompleting forms, but interesting)
• Find their UID on Flickr, which gives you a source for:
  • Full Name
  • Location
  • Flickr Avatar

If you know any of their social networking usernames, you can:

• find their MyBlogLog profile, if they’ve linked the service to their account (Sample query, I added my twitter). Now we have:
  • MyBlogLog Screen Name and ID, from which you get their MyBlogLog profile:
    • Nickname
    • Picture
    • Age
    • Sex
    • Location
    • A list of tags they use to describe themselves.
  • MyBlogLog Avatar

Those are only some of the proof of concept API’s that I’ve listed here. The interesting piece of this, is that once you have a small piece of information, it opens up the door to other searches.

One can only imagine how many leaves are in this tree. For example:

• Facebook’s Users.getInfo (in JavaScript)
• Yahoo’s Social Tools, get an end user’s GUID and go to town on their profile.
• Google Contacts, I didn’t even start to look through their API’s.

Before you start jumping the privacy fence to a self induced heart attack, remember that all this information has been volunteered by each individual participating in each of these services. Remember, with great power comes great responsibility.

What do you think? Scary or useful?

Download the Source Code

Here’s a use case. An unregistered visitor visits your blog, and decides that your content is so good that it merits a comment! Congratulations, you’ve fooled them! Now you can twply their account details for $1200 on Sitepoint! Just kidding. But generally, when you visit a blog’s commenting section (such as the Tournology Blog shown above), you’ll see a simple form to authenticate you’re not a spammer, generally including (among other things) an e-mail address field.

Well, since they’re typing their e-mail address, wouldn’t it be cool if we could show them their gravatar right there, inline with the blog comment form? Well, that’s now possible with my new JavaScript Gravatar Plugin! It doesn’t have any server side language dependencies.

Hell, gravatar.com could even use this to improve the user experience of registering your e-mail account. Right now it does a full page refresh and doesn’t even show you a preview!

See the Demo

Download the Source Code

Licensing

Licensed under the WTFPL, as highly recommended by Isaac Schleuter (see discussion).

JavaScript Dependencies:

• Requires jQuery (Feel free to port and post a link!)
• Requires md5.js

Example Usage:

Easiest form, onblur of email text input field:

$('#emailTextField').blur(function(event)
{
    $(this).after($.gravatar($(this).val()));
});

Showing all options, again onblur of email text input field.

$('#email').blur(function(event)
{
    $('body').append($.gravatar($(this).val(), {
        // integer size: between 1 and 512, default 80 (in pixels)
        size: 200,
        // maximum rating (in order of raunchiness, least to most): g (default), pg, r, x
        rating: 'pg',
        // url to define a default image (can also be one of: identicon, monsterid, wavatar)
        image: 'identicon'
    }));
});

• Prototype and Dojo are the only major JavaScript frameworks that correctly time the DOMContentLoaded inside of an iframe in Internet Explorer. MooTools comes close and both YUI and jQuery both exhibit incorrect behavior.
• Usually, browsers that have a native DOMContentLoaded event will fire it after both JavaScript and CSS (external script, link tags) have loaded. But Opera fires prior to CSS link tags loading.

We all know the problem, but we may not all call it the same thing. Every popular JavaScript library has its own name for the DOMContentLoaded event.

But the naming scheme isn’t the only part about this event that’s inconsistent. There are a few hacks strewn around the net that have been bastardized (read: modified to the will of library authors) into each individual framework. These have been posted time and time again, but for post completeness are the following:

Benchmark for Library DOMContentLoaded Implementations

I created a benchmark trying to answer the simple question: when does the DOMContentLoaded event fire? Each implementation has different effects, especially in iframes and with stylesheets.

What Works

The Internet Explorer hacks presented above are reliable when used on a standalone document (not inside of an iframe).

Mozilla Firefox, Safari, Chrome, and Opera all contain a native DOMContentLoaded event that each framework uses to consistently fire at the correct time. So, it isn’t even worth summarizing the results for tests in every browser with a native DOMContentLoaded event, except Opera. Opera took a different design approach with their DOMContentLoaded event (certainly not wrong, just different), which we’ll analyze below.

Internet Explorer inside an Iframe

All libraries below did no branching based on IE versions, all used the same method for IE6, IE7, or IE8. I performed no tests in IE8, however.

* For some reason, not only did the MooTools library not wait for the body script to trigger DOMContentLoaded, the body script never executed at all.

The most important takeaway from this blog post are the successful methods of faking DOMContentLoaded in Internet Explorer. The obvious library winners here are Prototype and Dojo, with the addDOMLoadEvent script also exhibiting correct behavior. MooTools is a close runner up, and I would be interested to find out why it didn’t execute the body script (that’s left for another day, or perhaps a generous commenter).

Opera 9.6

As you can see above, Opera typically will fire DOMContentLoaded prior to stylesheets loading successfully (ignoring the jQuery specific code to provide consistency cross-browser)

Thanks to Adam Koch for first pointing me in the direction of jQuery in an iframe ignoring DOMContentLoaded in IE.

Update: There is an open ticket for YUI on Sourceforge, and I’ve opened a ticket for jQuery on their Trac site.

You can monitor the jQuery bug in the bug tracker, or see the original research performed by Jamie Thompson. Here’s a better workaround that merges two different approaches used on Jamie’s page, which fixes $.browser.version instead of using $.browser.msie6. This is to be considered temporary until the next (fixed) version of jQuery comes out.

jQuery.browser.version = jQuery.browser.msie && /msie 7\.0/i.test(navigator.userAgent) ?
	"7.0" :
	jQuery.browser.version;

The project has allowed me to expand my knowledge of browser quirks, improving my frontend-fu with every closed support ticket. What does that mean for you? More blogs posts. Learn from my mistakes (and from those I’ve inherited).

This week presented an interesting, albeit decreasingly relevant scenario, where a customer was seeing performance problems when loading a simple web page in Internet Explorer 6. The only hint to the root cause was a claim that he witnessed “400 items remaining” in his status bar. Naturally, this took awhile, but at least we had somewhere to start: Apache access logs.

Consider the following (jQuery) code to add three new images to the page using JavaScript:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
    <head>
		<script type="text/javascript" src="jquery-1.2.6.min.js"></script>
		<style type="text/css">
		img.bacon { width: 100px; height: 67px; background-image: url(bacon.png); }
		</style>
   </head>
    <body>
        <script type="text/javascript">
		jQuery(function() {
			jQuery('body').append('<img src="spacer.png" class="bacon"/>');
			jQuery('body').append('<img src="spacer.png" class="bacon"/>');
			jQuery('body').append('<img src="spacer.png" class="bacon"/>');
		});
        </script>
    </body>
</html>

Note how each image being added dynamically has a background-image as well.

In a normal web browser (read: Internet Explorer 7+, Firefox *), this would result in the following Apache access.log (with an empty browser cache) with only 4 HTTP requests (ignoring favicon.ico, which is irrelevant to this study):

127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/ HTTP/1.1″ 200 657
127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/jquery-1.2.6.min.js HTTP/1.1″ 200 55774
127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207
127.0.0.1 – - [18/Oct/2008:22:59:09 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416

In Internet Explorer 6, however, this is the resulting Apache access.log (empty browser cache) with 8 HTTP requests:

127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/ HTTP/1.1″ 200 657
127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/jquery-1.2.6.min.js HTTP/1.1″ 200 55774
127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207
127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207
127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416
127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416
127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/spacer.png HTTP/1.1″ 200 207
127.0.0.1 – - [18/Oct/2008:22:57:48 -0500] “GET /ie6cache/bacon.png HTTP/1.1″ 200 5416

When a web browser parses your markup and sees three image tags with identical src attributes, it makes only one HTTP request to the server for that image, and the rest of the images are loaded from the local web browser cache (no more HTTP requests are made). This is standard behavior for all modern web browsers. But in IE6, as you can see from the above log, made 3 requests to the server for both spacer.png and bacon.png. Why?

Turns out there are two independent issues at play here:

1. The classic IE6 background-image flicker problem. This has been documented extensively, and the problem is that IE6 bypasses its local web browser cache for any image requests made for CSS background-images inserted on the page dynamically. The good news for this one is that the fix is a simple one.

   if(jQuery.browser.msie && parseInt(jQuery.browser.version, 10) == 6) {
     try {
       document.execCommand("BackgroundImageCache", false, true);
     } catch(err) {}
   }

   Note the simple check for IE 6 execution only. This is optional, but keep in mind that this problem is not present in IE7+. During your testing, also keep in mind that Mister Pixel reports (and I can confirm) that once you run this command, this setting will persist in your browser, even if you empty your cache and remove the code from your scripts. You’ll need to close your browser window to reset the setting to default.

   See also Dean Edwards’ and Hedger Wang’s studies on this issue for more information. But this is really only half the problem. This will fix the duplicate bacon.png HTTP requests, but we’ll still see 3 spacer.png HTTP requests in our logs.

2. The other issue is a separate but equal problem with IE6 caching. When inserting images with identical src attributes, IE6 will always go to the server (which means an extra HTTP request) for a new image. This is a documented feature in IE6, and the fix they have listed on their page isn’t ideal. The best solution here is to eliminate the need for spacer.png altogether. I can put these bacon background’s on a div tag just as easily, emphasizing pragmatism over semantics in this case (it’s a small sacrifice, you’ll live). If you have an <img> tag with a source you actually need, why not move it to the background image on a div tag? Unfortunately here, the takeaway is that your logic may need to be restructured to workaround this issue.

   See also Mihai Bazon’s study for more information, but do keep in mind that grouping this issue with the background flicker problem is an incorrect categorization. They are two separate issues and the fixes represented on that page don’t really fix the issue at all. Implementing server side caching as a “fix” is like using a bandaid for a tourniquet. You don’t want an HTTP request to go to the server at all, I don’t care if the response is a 200 OK or a 304 Not Modified. No HTTP request is always going to be faster than a server side cached response.

These issues will present themselves more frequently if you have the “Every visit to the page” caching option enabled in your Internet Tools in Internet Explorer. Good luck.

The most common usage of a relative URL is linked from the root (note the slash at the beginning), like so:

<img src=”/web/wp-content/themes/hemingway/images/title.png“/>

You can also use ../ to navigate up a directory in your path, but that’s boring. The interesting question is: what if I wanted to load content from a separate domain, while at the same time transparently using the protocol used on my page?

Do what Google Calendar does and use the following style:

<img src=”//calendar.google.com/googlecalendar/images/calendar_sm2_en.gif“/>

Note the lack of http: or https: from the URL. If this page were hosted on https (we don’t pay for certificates around here, so you’ll have to put up with the security warning), the last image source will load from https as well at no additional development cost.

This seems like it would be especially useful if you were using the YDN Performance tip to Split Components Across Domains. Remember, we’re not just talking images. This involves how the browser resolves URLs, so could be used inside href tags, css urls (as Google Calendar did), etc.