DOMContentLoaded Inconsistencies (in Browsers and JavaScript Libraries)

Zach Leatherman — Fri, 05 Dec 2008 04:54:24 +0000

Quick Summary

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.

JavaScript Library	Event Name
YUI	DOMReady
jQuery	ready
MooTools	domready
Prototype	dom:loaded
Dojo	addOnLoad

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:

IE DOMContentLoaded Hack	Description
`doScroll` by Diego Perini	Uses a `doScroll` method call, which will throw an error if the `ondocumentready` event hasn’t fired on the primary document (take note of the usage of the word primary). Once `doScroll` doesn’t throw an error, it is assumed the DOM has loaded.
`onreadystatechange` and `readyState`	`onreadystatechange` “fires when the state of the object has changed,” and changes the `readyState` property of the object through the following states (not all apply to every type of element): `uninitialized`, `loading`, `loaded`, `interactive`, and `complete`. (source: MSDN) Usually set on the document object, or a script element (as used in the Script Defer method described next.
Script Defer by Dean Edwards	document.write’s a script tag with a `defer` attribute. Defer will cause the browser to delay execution of the script until the DOM has successfully loaded (using onreadystatechange on the script tag until its readyState is “complete”). Without defer, the browser would execute any script tag immediately.
HTC Behavior by Dean Edwards	Much less popular approach using proprietary HTC Behavior files. Generally avoided due to the addition of an extra HTTP request to the page in order to download the external .htc file. As a side note, if using this approach, the `"oncontentready"` event will work better than the “ondocumentready” event used by Mr. Edwards.
Ghetto Method	Of course, the easiest way to do it is to put a script tag right above your ending tag that triggers the event manually. This really only works if you have full control of the content, and isn’t really a library solution. Worth noting though.

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.

JavaScript Library Method Waited for:

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:

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.
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 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.

Relative URLs including the Domain

Zach Leatherman — Thu, 16 Oct 2008 06:45:24 +0000

Just a neat little trick I saw while browsing the source code of Google Calendar. In some of their CSS files, they link to background-images using URLs that include everything but the protocol, which is something I hadn’t seen before.

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

/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:

//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.

Rethinking JavaScript Grids and DataTables

Zach Leatherman — Sun, 13 Apr 2008 20:29:26 +0000

In the world of front end engineering, one must consider the end-user of the interface first, and above all other things. The priorities should not start with development ease, nor external library preference. The priorities should start with the needs of the consumer of your end product.

Evolution of your engineering skill is also a vital trait in this world, which means that as a developer increases his knowledge of good practices and proper methods, sometimes he must shirk his previous assertions about the world as he previously knew it. And today I’m shirking a staple of the front end as all web users know it: The Grid (DataTable) Component.

Of course, I’ve written a few articles in the past about the YUI DataTable, during my long love affair with Yahoo’s User Interface library. Another popular one is jQuery’s TableSorter. Then there’s the Dojo Grid, a component inherited from TurboAjax. ExtJS has a variety of nice examples as well for their Ext 2.0 Grid.

And after using these Grids and DataTables, I certainly respect the programming that went into developing these components. But let’s take a step back for a second. Why do the users need the bells and whistles in these components? Are they worth the extra load time and complexity they add to the interface?

All we’re doing here is putting a nice coat of paint on a

tag. Sure, it might have some nice ancillary features like Ajax Data Loading, but those don’t really matter – they are things that can be easily performed with some good Ajax and DOM insert utility functions. In fact, most of the core features included in these components could be described as feature creep, and not beneficial to the end user at all. Feature creep contributes to code bloat, which means the user is downloading bytes to their web browser that they don’t need, which can hamper performance. Libraries usually have online examples of their components, and the include sizes are seen below. (Gzip compression not considered)

Name	JavaScript Size	Minimized	Link
YUI DataTable	216.6 KB	Minimized	Example
Dojo Grid	338.4 KB	Unminimized	Example
Ext Grid	545.5 KB	Minimized	Example
jQuery TableSorter	66 KB	Minimized	Example

The JavaScript include sizes listed above are directly proportional to the feature set that the components provide, and should give you an idea of the overhead involved with using them. Do we need 545.5 KB of features coming down the pipe to give our users an extra bell, or an extra whistle? Let’s analyze the features to rationalize their usage, and remove items from the feature set.

Sorting
Modifying column order and display
Resizing columns
Editing of row data directly on the grid itself
Scrolling
Pagination

Sorting

Data should be used in the context of its usefulness. You have a list of messages in your e-mail inbox. What’s the most useful context for this list? In order of date received. The default sort order provided by the application, to facilitate proper use of the application. Is comparing the rows in the grid by any other method as useful? Does the user need to see the list of messages ordered alphabetically by subject? In these cases where the user is in need of a specific message, searching and filtering is more useful than sorting. The default sort is useful, but allowing the user to resort on the client, in most cases, is not as useful as other methods of finding a row.

Modifying column order and display

The same argument can be made for any of the other methods of customization provided to the end user. Does the user need to reorder or hide columns? The context provided by the application should be sufficient to use the applications data in the way it was intended. Don’t overcomplicate your user interface with needless features or a deluge of useless data. Provide succinct, appropriate data, and the user needn’t reorder or change the interface.

Resizing columns

The default HTML

tag expands to fit the data inside of its cells. Even when you set the width of the table explicitly, the cells adjust themselves accordingly to fit the data. This should be the behavior of your table. You needn’t monkey around with widths, the browser is smart enough to do it for you. You can even customize a cell to wrap its text to multiple lines with CSS, if need be.

Editing of row data directly on the grid itself

If you’re providing an Excel spreadsheet interface for the end user to customize your data, you haven’t designed your interface correctly. Rethink how the user needs to interact with the data you’ve provided, and give them a better, simpler way to edit the data.

Scrolling

Everyone knows that internal scrollbars on a page are evil. I don’t even like scrollbars on textareas, to be honest. Previously, I had worked and reworked the YUI DataTable to handle horizontal scrolling. Looking back on this, it was a mistake. There are better ways to handle lots of data in a table, without the heavy mouse interaction and scanning that scrolling require. Which brings me to my next point.

Pagination

This is the one exception to the feature set cutting board. This is the one feature that’s is a requirement, when the data set has too many records to fit on a single page.

Keep these in mind, and look at the feature set provided by a few sites using tabular data centric interfaces that know a thing or two about interface design:

So, what should we include?

A simple CSS class to style your table is sufficient, with links to paginate the table (properly) and/or a hover for row selection if needed. You’re looking at 10-20 lines of jQuery code, maximum, and a few CSS declarations. In lieu of sorting, of course, you’ll need to program in a mechanism for searching and filtering as well. But really, the difficulty with programming this component is knowing what to leave out.

Web 3.0, 6 Bladed Razors, 7 Minute Abs » linkedin

DOMContentLoaded Inconsistencies (in Browsers and JavaScript Libraries)

What Works

Internet Explorer inside an Iframe

Relative URLs including the Domain

Rethinking JavaScript Grids and DataTables