Is Your JavaScript Library Standards Compliant?

One of the things JavaScript libraries like jQuery, Dojo, and YUI can do for you is add support for features in the latest Web standards long before they are built into browsers. But are some libraries going too far?

For the developers of JavaScript libraries, there is a temptation to extend the features of the standard, and build something even better! A good example of this is the CSS selector queries that first made jQuery famous, but which are now available in most JavaScript libraries.

CSS queries provide an extremely convenient way of getting a list of elements from an HTML document that match certain criteria. As an example, you might write a script that opens all hyperlinks with the attribute rel="external" in a new window. Using just the DOM API supported by all major browsers, the JavaScript code to retrieve that list of links is pretty cumbersome:

var anchors = document.getElementsByTagName('a');
for (var i = 0; i  0 &&
      rel != null && /(^| )external( |$)/.test(rel))
  {
    // anchors[i] is a link with rel="external"
  }
}

This code starts out by getting a list of all a elements in the document, then checks each element in that list to see if it has an href attribute and a rel attribute that contains the word external.

A CSS query lets you express all these tests using the same compact CSS selector syntax we get to use when writing style sheets. Here’s how it looks using jQuery’s CSS query API:

var links = $('a[href][rel~=external]');
for (var i = 0; i 

This feature proved so popular, that it was quickly added to every JavaScript library of note. Here’s the same thing using Dojo’s API:

var links =  dojo.query('a[href][rel~=external]');
for (var i = 0; i 

While the various libraries battled it out to produce the fastest implementation of CSS queries, the browser makers got together at the W3C and nutted out a standard that browsers could implement natively: the Selectors API.

But here’s where things get interesting: some of the libraries, like jQuery, have added support for a whole bunch of extra selectors on top of those provided by the CSS specs, while others, like Dojo, have stuck to supporting standard CSS selectors only.

Obviously, when browsers support the Selectors API (Safari and IE8 beta 1 already do!), their native implementations will run faster than anything a JavaScript library can do. But the Selectors API only lets you use CSS selectors supported by the browser—no more, no less. Libraries that support additional, non-standard selectors will not be able to deliver this performance boost.

Here’s how Dojo’s Alex Russell put it in his announcement of the recently-released Dojo 1.1:

…by keeping our query syntax to just what CSS provides, we’ve avoided getting ourselves into a situation where we’ll always need to be shipping such a query engine down the wire. Sooner or later, dojo.query() will become nothing more than a call into querySelectorAll plus some syntactic sugar on the returned array. Best yet, API won’t change and you can get the speedup on the browsers that support it now, knowing full-well that things will only get faster and smaller in the future. An investment in a toolkit that [pays] attention to the evolution of the web is already paying dividends for Dojo users.

So, which JavaScript library do you use, and have you checked how its APIs compare to the emerging standards for equivalent built-in browser features?

Updated the code samples above to use for loops instead of for…in loops based on the feedback in comments.