The Mankini’s development predated the HTML5 specification but the end result was functionally similar. The difference being that in addition to operating on text inputs and textareas, it also worked with LF/CR and selects (injects an option with an empty value). The HTML5 specification requires that LF/CR be stripped from the placeholder value.

One of the most important design considerations our interaction design team specified for The Mankini was that it was not to be used as a replacement for a form label. It was a complement to the form label and nothing more. The HTML5 specification came to the same conclusion: “The placeholder attribute should not be used as an alternative to a label.” The reasoning is obvious: if the form field has a non-empty value, you need to be able to easily identify the value’s semantic meaning.

Instead of putting the label text into the placeholder, use the placeholder to supplement the labels with an example e-mail and URL to provide more of a hint to the user for proper formatting. This example isn’t a huge usability issue since the three fields’ values would be easily identifiable, but it’s important to keep in mind.

Placeholder Testing

I decided to run a few compatibility tests on the placeholder attribute to see where I could reuse the HTML5 placeholder inside of The Mankini (the test results are also available on GitHub). This yielded a few interesting things about some consistent and inconsistent cross-browser incompatibilities with the specification that I thought were worth sharing.

1. The HTML5 spec states that the placeholder should be visible when “element’s value is the empty string and/or the control is not focused.” The and/or presents the implementor with a decision. Do they keep the placeholder text visible when the field is focused but the value is still empty? Or do I remove the placeholder when focusing into an empty field?
   
   My personal preference is that the text remains until the user starts to type. Safari 5.1, iOS 5, and Chrome 17+ were the only browser implementations to agree with this as of time of writing.
2. The HTML5 spec has suggested (not required) that placeholders only apply to <input type="text|search|password|tel|url|email|number"> and <textarea>. For some input types such as hidden, radio, or checkbox this limitation makes sense, the placeholder would add nothing to these elements. But for others like datetime, date, month, week, time, datetime-local, color, or file the argument can be made that it would be useful.
3. There is an open WebKit issue to add placeholder support to contenteditable. Hopefully the specification gets modified and this gets added, as it would have been useful for my BigText Demo Wizard which manually implemented that same feature.
4. <input type="number"> support is broken in Safari and it’s already been reported and fixed. “The future is here, just not evenly distributed.”

As a side note, it should be said that both Opera and iOS both have comprehensively badass support of the new HTML5 form element types.

Overlooked Polyfill Considerations

• For those browsers that did implement the placeholder, it was well supported in password fields, showing as plaintext and then converting to masked input when the user started to enter data. This was a nice surprise, but polyfilling that behavior in old Internet Explorers will require additional lifting since dynamically changing the type attribute is not permitted.
• Placeholder text should not be included with form submit.
• Placeholder text should reinitialize on form reset (note: there is no delegate event for reset in jQuery)
• Performance. Is the component required to iterate over all elements and add a class to initialize each one individually? For best performance, use CSS attribute selectors (input[type="text"][placeholder]) for the default style and iterate only to remove the light gray color on form elements with non-empty values. This only requires a className modification for a much smaller set of elements, only the ones with non-empty values. Remember that the browsers we polyfill are often the slowest.
  
  Does the component modify the className property on focus and blur? I found this to be a huge performance issue for the Mankini in IE7 and IE8 on pages with large DOM trees and was a lot faster if the Mankini only modified one element’s style (think jQuery’s $(this).css('color', '#000')).
• Clear the values on page unload. After page refresh, some browsers will attempt to save unsubmitted form values and re-enter the values when the page reloads (added after reviewing Mathias Bynen’s jQuery-placeholder).

Bathwater, No Babies

HTML5 Please recommends that we use the new and shiny responsibly and gives the go-ahead to use the placeholder polyfill on our pages. I humbly disagree. This seems to be the same trap we fell into for rounded corners and box shadows. We put extra effort into trying to get our sites to render and behave identically cross-browser, when we should have just let them render in old browsers without rounded corners or box-shadows at all. To test whether or not a polyfill is necessary, I created a super complex decision workflow called The Polyfill Test. It consists of 2 steps:

1. Look at your own browser statistics. If the feature is at >50%, continue to Step 2.
2. Determine if the user be able to complete their task without the feature. If the task is still completable without significant impairment, the polyfill isn’t necessary.

Globally, placeholder support is sitting at 60% and growing. This particular feature has passed the tipping point. If your audience isn’t a representative sample of the global web browser statistics (big enterprise intranets with 97% Internet Explorer), your mileage may vary.

If you’re already using validation on the form fields (client and/or server side) and you’re correctly using the placeholder to supplement (not replace) the field labels, I would argue that the polyfill isn’t needed. It’s an implementation nice-to-have, not a requirement.

Update: Added note about Chrome 17+ support for placeholder text remaining on focus per Mathias’ feedback below.

Earlier this year I was given the opportunity to attend the jQuery Conference in San Francisco. I was delighted to go, able to finally meet some of the JavaScript greats I’d been stalking following online for years.

Looking back on the conference, the one presentation that had the biggest impact on the way that I code had to have been Dan Heberden‘s “Deferreds, Putting Laziness to Work.” (I would be remiss if I didn’t also mention inspiration from a recent presentation by Eli Perelman at the Omaha jQuery Meetup.)

At first, Deferred objects sound scary. I can assure you that they’re actually incredibly easy and incredibly useful. Today we’ll go through the simple task of reworking the Geolocation API to use jQuery Deferred objects.

Here is the standard Geolocation API to retrieve the user’s current position:

navigator.geolocation.getCurrentPosition(function(position) {
  // success
}, function(error) {
  // failure
}, {
  // options
  enableHighAccuracy: true
});

When the above API is called, a prompt is shown to the user asking if they want to divulge their location information to the domain of the currently active web site. Typically this prompt is a non-blocking asynchronous operation (although not explicitly defined in the specification).

Let’s go ahead and change it to use a jQuery Deferred object:

function getCurrentPositionDeferred(options) {
  var deferred = $.Deferred();
 
  navigator.geolocation.getCurrentPosition(deferred.resolve, deferred.reject, options);
 
  return deferred.promise();
};

Notice that the success callback is replaced by the deferred object’s resolve method and the error callback is replaced by the reject method. All of our function arguments are removed from the API. We’re left with one simple options argument.

This allows us to do things like:

getCurrentPositionDeferred({
  enableHighAccuracy: true
}).done(function() {
  // success
}).fail(function() {
  // failure
}).always(function() {
  // executes no matter what happens. I've used this to hide loading messages.
});
// You can add an arbitrary number of callbacks using done, fail, or always.

We could also use $.when to run code upon completion of two arbitrary and contrived operations like a Geolocation call and an Ajax request. Awesome.

To coordinate between multiple Deferred objects, use $.when:

$.when(getCurrentPositionDeferred(), $.ajax("/someUrl")).done(function() {
  // both the ajax call and the geolocation call have finished successfully.
});

I wonder what other browser native APIs could be better served by using Deferred objects instead of function arguments.

We at @paravelinc happily present to you FitText—a jQuery plugin for inflating web type: http://t.co/1NuQg5z

Naturally, I wondered how it compared to BigText, a plugin of my own creation to Make Text Big. Trent continued:

It’s in the GitHub readme, but I want to recognize BigText from @zachleat as another font sizer for non-fluid sites: http://t.co/dXw607P

I was delighted to get some attribution from Trent, and even more delighted to see their plugin. It’s really a great piece of work. However, his statement that BigText is just for non-fluid sites is not quite accurate. Let’s dive in.

On the surface, BigText and FitText might seem very similar. In fact, they are quite different and approach what might seem to be a similar problem (resizing text to fit a container) in very different ways.

At its simplest, we can boil it down like this: If you’re crafting a specific design with copy that is not going to change, use FitText. If your text is dynamic (maybe user generated), use BigText.

Here’s more detail:

FitText is very lightweight and fast, even considering it doesn’t yet use a debounced resize event. The FitText algorithm is quite beautiful. A huge well done to Paravel.

FitText relies on the fact that there is a linear relationship between font-sizes and element widths. Once you’ve established the ratio between the two, it’s off to the races. In fact, it would probably be technically possible to determine the ratio solely on the initial inner-width of the text and the initial font-size. I’ll have to play around with that approach but if it works it would give an amazing speed improvement to BigText.

In a perfect world, BigText and FitText could be combined, to create a mutant auto-text-sizing plugin baby that gives the best of both worlds.

He wins a copy of Christian Johansen‘s book, Test-Driven JavaScript Development.

If you code for a living, testing will make your life easier. Even though the contest is over, I encourage you to go through the steps and complete the original challenge, if for no other reason than to see how easy it is to get a simple testing environment set up with JsTestDriver.

Stay tuned for more coding challenges!

Related: An Update to The JavaScript Testing Challenge

Here’s Steve’s screencast (using, I assume, a mechanical keyboard?):

Please note that the following information may be common knowledge, as this behavior is as described in the pre-requisite Microsoft documentation on the subject. However, I feel this behavior to be unintuitive and requiring more explicit communication.

Library developers live in a much different world from full stack developers. If you’re supplying code that will be used by others, you’re faced with a different set of priorities. As such, the library I manage provides certain user agent sniffing conveniences, namely classes to replace CSS Hacks (similar to the approach used in HTML Boilerplate to provide ie6 through ie9 classes on the <html> tag) and JavaScript booleans (similar to jQuery.browser). Much like jQuery, these conveniences remain for backwards compatibility.

The purpose of this post is in fact not to convince you whether or not User Agent Sniffing is a good tradeoff for performance (even though, in some cases I believe it is), but instead to provide further evidence that using the User Agent alone is an unreliable method to determine the rendering engine of the web browser, and must be complemented with other approaches. If you’re going to sniff, you have to sniff harder.

X-UA-Compatible Breaks navigator.userAgent

Microsoft defines two terms to help communicate how new versions of Internet Explorer render a page: Browser Mode and Document Mode. Browser Modes are determined prior to any request made to the server (and cannot be changed by web developers). If the user triggers an IE7 Browser Mode using the Compatibility View Button, a new request is made to the server. Document Modes are determined in the page response.

Compatibility View Button Flow

1. User presses the Compatibility View button. This changes the Browser Mode.
2. Request sent (since the Browser Mode has changed, the User-Agent is also changed to MSIE 7.0)
3. Response from Server
4. Document Mode determined

X-UA-Compatible Flow

1. Internet Explorer uses the default Browser Mode (newest available in the browser)
2. Request sent (Browser Mode determines User-Agent to send, probably MSIE 8.0 or MSIE 9.0)
3. Response from Server. Content may include X-UA-Compatible <meta> tag and/or Response HTTP headers such as X-UA-Compatible).
4. Document Mode determined, using X-UA-Compatible and the DocType

If a X-UA-Compatible header is sent back in the Compatibility View flow, it will take precedence but obviously will not change the request User-Agent HTTP header.

It’s important to note that since the request has already gone before the Document Mode is determined, the Document Mode has no bearing on the request User-Agent HTTP header. While Microsoft probably could have changed navigator.userAgent to be different than the request User-Agent HTTP header, I feel they made the correct decision is keeping the same value. navigator.userAgent remains the same value as the request User-Agent HTTP header in IE8, but Microsoft changed this behavior in IE9. In IE9, navigator.userAgent represents the document mode, not the request User-Agent header.

The User Agent isn’t the only thing being determined. The prerequisite Microsoft documentation states that the Browser Mode determines the User Agent, Default Document Mode, and Conditional Comments. This is not accurate. The Document Mode determines which Conditional Comments execute, not the Browser Mode.

Also note that using IE’s Conditional Compilation feature to return the version of JScript will be the same, independent of Document Mode.

var ie = /*@cc_on @_jscript_version+@*/0;
// Always returns 5.8 in IE8, independent of Document Mode.

Example Code from Scott Jehl’s respond.js

Test Pages

Try the following tests in Internet Explorer 8+ to test for yourself.

• Stock Page
• Setting X-UA-Compatible IE=7 using a Meta Tag (or IE=EmulateIE7)
• Setting X-UA-Compatible IE=7 using an HTTP Header (or IE=EmulateIE7)

What Does This Mean?

If you use X-UA-Compatible to change the Document Mode/IE Trident rendering engine, any client side code relying on navigator.userAgent (such as jQuery.browser) or server side code relying on the User-Agent HTTP Header will be incorrect. Since we can’t rely on the User Agent, what can we use? Microsoft does provide a document.documentMode integer we could use, pretty easily. But, I think there is a better approach.

Consider a great piece of JavaScript written by James Padosley to find Internet Explorer version numbers using Conditional Comments. His code seemed to meld perfectly with the above realization that the Document Mode determines Conditional Comment execution. We can use this to fix jQuery.browser.

// Place this script after jQuery, but before any code that uses jQuery.browser
// Modified to only test for IE 6+, since jQuery only supports 6+
(function($)
{
    if(!$.browser.msie) {
        return;
    }
 
    var v = 5,
        div = document.createElement('div'),
        all = div.getElementsByTagName('i');
 
    while (
        div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
        all[0]
    );
 
    $.browser.version = v;
})(jQuery);

Now, of course, since we’re creating nodes there is a small performance penalty in using the above script over Regular Expressions and document.documentMode. I feel this to be worthwhile, given that I’ve been burned by Internet Explorer’s version number before. But next time, I reserve the right to choose performance over simplicity.

It all began with a simple web foray to Designing Monsters. Their simple, typographic design was beautiful. But why? Their combination of the beautiful League Gothic font, use of Lettering.JS, and some simple font scaling gave the page a wonderful consistent vertical alignment. Like the Million Dollar Homepage, I wanted to rebuild it — but I didn’t want to spend a lot of time manually adjusting font sizes. So I did what any programmer with the jQuery Golden Hammer would do, I turned my problem into a nail.

At it’s simplest, the BigText jQuery plugin takes a single element and sizes the text inside of its child <div>s to fit the width of the parent element. Gives the text that lovely vertical alignment.

<div id="bigtext" style="width: 300px">
    <div>The elusive</div>
    <div>BIGTEXT</div>
    <div>plugin exclusively</div>
    <div>captured on film</div>
</div>

$('#bigtext').bigtext();

See the above at JSFiddle.

Implementation Details

The plugin itself is more than just a simple font-size incrementer. I wasn’t happy with the performance of simply iterating through font sizes with a single fixed interval. I decided it would be better to test multiple decreasing intervals. For each line, it increments first by 16em until it detects a line break, backs off an interval then increments by 8em. It continues with 4em, 2em, 1em, 0.1em, until it finds the correct font-size to the nearest hundredth of an em. It’s noteworthy that Webkit does not respect font-sizes to the nearest hundredth, it’s precision is maxed out at tenths. This algorithm results in fewer tests in most cases, especially where the resulting font-size will be very large. Performance is always important. After font-size, it moves to word-spacing as a backup for extra precision, especially needed on Webkit.

The BigText Demo Wizard

Check out the Demo

This is where the magic happens.

• Editable text (contenteditable), and BigText will run on every keyup event to resize what you’re typing.
• Dynamic horizontal and vertical centering using Alex Russell’s Flex Box CSS classes (This is easy now, hooray!)
• 3D transforms (browser support checked using Modernizr, currently only available in Safari. Note: Chrome flattens to 2D space)
• Custom fonts are loaded using Google’s Font Loader JavaScript API
• Ben Alman’s Throttle Plugin
• The rest is mostly jQuery UI with the Aristo theme

Turns out, the BigText Demo Wizard makes for really easy Kinetic Typography screencasts (not amazing, but surely easy):

The above is simply the manual process of typing lyrics into the BigText Demo Wizard. You can easily make one of these too, with the help of the following keyboard shortcuts:

• CTRL + ALT + X: Set the text to a random 3D transform angle.
• CTRL + ALT + C: Toggles between white and black background.
• CTRL + ALT + R: Reset 3D to default state.
• CTRL + ALT + SPACE: Fade out current text, clears the text, sets a random 3D transform angle, ready to type!
• CTRL + ALT + ENTER: Same as CTRL + ALT + SPACE, but keeps the same 3D transform angle.

The fun part about the BigText Demo Wizard for me was that it almost turned into a non-musical instrument when I used it real-time to complement music. Feel free to cruise Pandora and type lyrics to the music until your wrists get sore. What can you make with it?

The BigText Demo Wizard was tested manually in Safari 5, Chrome 8, Opera 11, Firefox 3.6, and Internet Explorer 8. The BigText jQuery plugin has a full JsTestDriver suite, available on GitHub. Just run ./test.sh or test.bat

In The JavaScript Testing Challenge, I asked JavaScript developers of the world to change their heathen ways and embrace the future of automated testing for a healthier and brighter tomorrow.

However, due to seasonal timing or otherwise real life related reasons, the challenge was greeted with a worldwide chorus of universally blank stares. So, in the true spirit of Christmas, I’m removing the deadline and will award the grand prize to the developer with the first correct and complete PrimeFactors code kata screencast. That’s right, be the first to answer the challenge will win a copy of Test-Driven JavaScript Development by Christian Johansen (PDF or Print version, your choice).

If you have any questions or need help getting started, let me know! I’d be glad to help. Good luck!

Update: An Update to The JavaScript Testing Challenge

Think back to the last time you wrote new code from scratch. Not autogenerated Dreamweaver image hovers or a pasted script from Dynamic Drive, but pure unadulterated new code. What was your process? I’m betting it’s probably similar to: (1) code, (2) switch to a browser, (3) confirm desired behavior for the change you’ve made, and (4) repeat.

Comrades, let me assure you that there is a better way, and it starts with writing unit tests. As a Front End Engineer that’s been doing it bareback without tests since I started in 1997, let me assure you that adopting automated testing strategies is one of the single best changes I’ve made to my development cycle to make myself more productive. Enough fluff. Let’s get started!

Testing Environment Setup in 3 Steps

Prerequisite: Java on the classpath

1. Download the JavaScript-Code-Katas Source (ZIP) (or checkout the code from the Github Repository, if you have git available)
2. Extract and browse to it using your operating system’s command line.
3. Run (Windows)
   > JsTestDriver.bat Template

   Run (MacOS)
   $ ./JsTestDriver.sh Template
   This script will close Safari (be careful if you’re using Safari in other windows)

If a web browser popped up on your screen, congratulations! You have an automated testing environment set up and running. Easy, right?

Writing a Test

Now, let’s write our first test!

1. Open up templateTest.js in your favorite IDE.
2. Add the following:

   TemplateTest = TestCase('TemplateTest');
   TemplateTest.prototype.testSample = function()
   {
       assertTrue(true);
       assertFalse(false);
       assertEquals(true, true);
   };

3. Re-run the JsTestDriver shell script from Step #3 above.

Now you should see something like the following:

Total 1 tests (Passed: 1; Fails: 0; Errors: 0) (2.00 ms)
  Safari 533.18.5 Mac OS: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (2.00 ms)

Notice how you didn’t have to touch any HTML boilerplate code or manually bring up a web browser? Productivity ensues! You’ve made it this far, are you brave enough to dive into a Code Kata?

Prime Factors Code Kata

Code Katas are just small programs used as practice. They’re a great way to introduce Test Driven Development and improve proficiency with your IDE.

The Prime Factors Code Kata requires a function that takes a single integer argument and returns an array of prime factors of that argument in ascending numerical order. For example, passing in 8 should return 2, 2, 2.

• Original Java version by Uncle Bob Martin (see original post).
• JavaScript implementation of the Prime Factors algorithm

I’ve recorded an unmodified single-take screencast of myself performing the kata below. I’m using the same source code I provided above, but with the JsTestDriver Eclipse plugin instead of using the command line to run the tests. The plugin is great for the screencast, because it very easily shows when the tests are failing or passing. You might also notice that it reruns the tests automatically every time I save.

JsTestDriver

If you want to learn more a about JsTestDriver, check out their Google Code page. “But I use QUnit!” you say. That’s fine, there is an adaptor for that. Using both tools together, you won’t need to launch each individual browser manually and trigger the tests to start. It will save you time.

Challenge

Testing will help you. It will improve your the quality of your code and your productivity. I challenge you to practice the JavaScript Prime Factors Code Kata in your own IDE with your own automated testing process. Send a link to me on Twitter (@zachleat) with an unmodified single-take screencast of you performing the kata (in JavaScript) by December 25, 2010 and the fastest kata screencast will win a copy of Test-Driven JavaScript Development by Christian Johansen (PDF or Print version, your choice*).

Screenr is a great tool for recording screencasts, if you need one.

Good luck!

Or, I Am Dynamically Loaded CSS (and So Can You!)

Dynamic resource loading is one of the keys to have a performance happy web application. There are generally three different criteria we must address when making a request: cross domain security policies, asynchronous/synchronous (will it block the host page while loading), and whether or not events are triggered when the request completes.

If the resource and host page are on the same domain, obviously XMLHttpRequest works the best. We can control whether or not the resource is loaded asynchronously or synchronously, and we know exactly when it gets done.

If the resource and host page are on different domains (increasingly more common with CDN’s), our options narrow. Loading the JavaScript is a solved problem, just use the onload event on the <script> tag and you’re good to go (onreadystatechange for IE). But CSS is more complicated.

Existing Solutions

In all of the library source code I evaluated, Internet Explorer didn’t cause any issues. It fires both the onload and onreadystatechange events for <link> nodes. Obviously this is ideal behavior, and IE got it right. But what about Firefox and Safari/Chrome?

YUI 2.8.1 and 3.1.1

Original Source

// FireFox does not support the onload event for link nodes, so there is
// no way to make the css requests synchronous. This means that the css 
// rules in multiple files could be applied out of order in this browser
// if a later request returns before an earlier one.  Safari too.
if ((ua.webkit || ua.gecko) && q.type === "css") {
    _next(id, url);
}

I wouldn’t be surprised if the commit log there was from Bon Jovi; that code is living on a prayer.

LazyLoad

Original Source

// Gecko and WebKit don't support the onload event on link nodes. In
// WebKit, we can poll for changes to document.styleSheets to figure out
// when stylesheets have loaded, but in Gecko we just have to finish
// after a brief delay and hope for the best.
if (ua.webkit) {
    p.urls[i] = node.href; // resolve relative URLs (or polling won't work)
    poll();
} else {
    setTimeout(_finish, 50 * len);
}

Better, closer, warmer. This includes a nice method for working with webkit browsers. The poll method compares document.styleSheets, since Webkit has the nice option of only appending to the styleSheets object when the styleSheet has successfully loaded.

So we have working solutions for IE and Safari/Chrome. The only unsolved piece of the puzzle here is Firefox.

This post from the same author as LazyLoad also describes another solution which involves modifying the source CSS and polling against it. But that’s not really ideal. Can we do better?

Solution

Here’s what I came up with (using jQuery for brevity, note that this solution only fixes Firefox, and does not incorporate the above already solved solutions):

var url = 'css.php',
    id = 'dynamicCss' + (new Date).getTime();
 
$('<style/>').attr({
    id: id,
    type: 'text/css'
}).html('@import url(' + url + ')').appendTo(document.getElementsByTagName('head')[0]);
 
function poll()
{
    try {
        var sheets = document.styleSheets;
        for(var j=0, k=sheets.length; j<k; j++) {
            if(sheets[j].ownerNode.id == id) {
                sheets[j].cssRules;
            }
        }
        // If you made it here, success!
        alert('success!');
    } catch(e) {
        // Keep polling
        window.setTimeout(poll, 50);
    }
}
 
window.setTimeout(poll, 50);

See this demo in action. (Firefox only)

Update: After much joy and celebration, I have discovered that an approach similar to the above was written by Oleg Slobodskoi in his xLazyLoader plugin for jQuery. It shouldn’t be surprising that two independent developers might reach the same solution, and is just more proof that software patents are stupid. :)

Update #2 Added note about HTML5 async property on script tags.

As many of you may already know, my day job includes managing a large and complex enterprise jQuery-based user interface component library. It’s used by all new web applications at the company, which boasts over an IT department of approximately 1500 people and hundreds of web applications. Needless to say, I get a fair volume of interesting support tickets that come my way. A few weeks ago, I had the pleasure of receiving one such ticket.

The support ticket’s symptoms included a oft-heard complaint: poor performance. On the web, poor performance can be attributed to a great many things, but most often can be boiled down to a bottleneck in JavaScript code using the DOM API. This time, strangely enough, the culprit was something else entirely.

One of the first things I check when an application complains of poor performance is the total size of the document, or how many nodes it has. One of the best ways to ensure good performance is to keep your document small, especially on projects using heavy dynamic element selection and filtering (think jQuery, Mootools, Prototype, Dojo, or any code using a selector engine like Sizzle). Any JavaScript library emulating CSS selectors executing over a very large document is going to take quite a bit longer than querying a small document, especially when the user’s browser doesn’t support native querySelector or getElementsByClassName.

To get an idea of what the size of a large document is, I usually go to a site with some fairly advanced JavaScript and query their size.

// Returns the total number of nodes in the document
document.getElementsByTagName('*').length;
// note: this number will not include any child nodes inside of iframes.

Getting back to the support ticket in question. After querying the document, I quickly found that the page contained over 50000 nodes. Wow. So, we’ve caught a big one. You’re going to be telling your grandkids about this some day. But, now what?

I decided it would be beneficial to find out where and what all of those nodes were. After clicking around the live document in the Firebug’s HTML tab for awhile, looking at View Source, and Ajax requests in the Console, I successfully determined the culprit. This particular application was using Wicket, a popular Java library for web applications, which includes its own Ajax Logger component (similar to my favorite log4javascript; or something like the YUI Logger), used to keep track of an application’s Ajax calls and JavaScript page manipulations with an inline GUI embedded in the parent document. On one page load, this application’s Ajax logger component had created 40000 nodes of log content.

It’s important to realize that embedding unnecessary content of that magnitude on the page can be very detrimental to performance. JavaScript loggers should log to a new child window, rather than be embedded in the parent document. This way they won’t bloat the document, but still provide you with much needed logging information.

But, in the future, how might this type of problem be more easily diagnosed and prevented? Ideally, when confronted with large documents, we want to see where in the document the majority of those nodes are located. But there isn’t an easy way to see which portion of the document is using the largest number of nodes, especially if the culprit is deep into the document tree. We can go through the source code manually, but that isn’t very efficient.

So in the spirit of exploratory development to help troubleshoot real-world problems, I decided to make a Firebug Lite plugin. This would give me an easy cross-browser tool to diagnose my problem in a familiar interface. Load up Firebug Lite, load the DOM Sailbloat JavaScript file, and easily spot the HTML love handles.

Here’s what it looks like in action:

Go Forth

1. See the demo
2. Download the source
3. Fork the Sailbloat on GitHub

Note: there is currently an undiagnosed issue with the Sailbloat and it fails to load intermittently. If you know why, I’d be happy to put your name in the source code credits.

When you see issues with Character Encoding, it’s traditionally in the form of text on your page that looks like this: in Firefox or in IE.

Usually, those characters mean that the character encoding used on the page is either ambiguous (not specified), or incorrect. We can use Firefox to determine that Character Encoding of a web page (Right Click and go to View Page Info; or use the “Character Encoding” entry in the View menu). Check to make sure that the encoding reported by Firefox is the same encoding used in your IDE. For example, Eclipse 3.5 has a “Set Encoding” option in the Edit menu.

The reason most English alphabetic and numeric characters are consistent independent of character encoding is due to consistency in the lower characters in each encoding. The characters making up the ASCII character set (0-127) are the same as the lowest 128 characters of ISO-8859-1, UTF-8, and others.

Managing your character encodings gets trickier as you add more architectural layers to your application. For example, character encodings may differ in your database, the properties files used to configure your application (java.util.Properties uses ISO-8859-1 by default), or maybe the XML or JSON file you’re loading from an external API.

Ever heard of HTML character entities? That’s the primary reason they exist — as a sort of encoding independent reference to a particular character. So, for example, the Œ character does not exist in the ISO-8859-1 character set. To display this character in a document with ISO-8859-1 encoding, use the equivalent HTML character entity: Œ. For an easier reference, check out this full table of HTML character entities. If using ISO-8859-1 for your HTML document, any entity above Unicode index 255 will need to be escaped. If you’re using UTF-8 encoding, HTML character entities shouldn’t be required.

Setting the Character Encoding

To specify the character encoding for any file, you can set a Content-Type header by configuring your web server or application. Apache lets you easily set different default character encodings for each individual file extension (.js for example). Using the Content-Type header is the most full proof and efficient ¹ method to serve content.

But without access to the Apache configuration, how do we specify the character encoding?

For external JavaScript Files

In the HTML File

Just add the charset attribute. If not specified, the HTML document’s character encoding is used by default (specified in the Content-Type header or the appropriate meta tag, for example: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>).

<script type="text/javascript" src="script.js" charset="utf-8"></script>

In the JavaScript File

To my knowledge, there is no way for a JavaScript file to report its own character encoding. To me, this seems like an omission. Each individual document should be able to report its own character encoding without a header. CSS files can do it (@charset at-rule). HTML files can do it (<meta> tag). Why not JavaScript files?

For Dynamically Created Script Tags

var s = document.createElement('script');
s.src = 'script.js';
s.type = 'text/javascript';
s.charset = 'utf-8';

If you’re using jQuery’s Ajax functions to load external JavaScript files, perhaps you might be inclined to use the script dataType. jQuery even provides a scriptCharset option for wrapping the above method for changing the charset on a dynamic script tag. Be warned, the jQuery Ajax function uses two different methods to load external script files (as of version 1.4.2). If a same-domain request, it uses an XMLHttpRequest. If a cross-domain request, it uses a dynamic script tag. So the scriptCharset jQuery option only applies to cross-domain requests. We’ll need some other method to mitigate our character encoding issues (or just use dynamic script tags).

For XMLHttpRequest Objects

Our saving grace would be the overrideMimeType method, if it weren’t poetically unavailable in Internet Explorer. Using this method, we can override the mime type and character encoding.

var xhr = new XMLHttpRequest();
// Not available in Internet Explorer (up to version 8 at time of writing)
if (xhr.overrideMimeType) {
    xhr.overrideMimeType('application/x-javascript; charset=utf-8');
}

Portable non-ASCII JavaScript

The best way to make non-ASCII characters in JavaScript files portable is to escape the characters properly. If the character is destined for HTML, use an HTML character entity (if available, not all Unicode or ISO-8559-1 characters have entities). Or, escape the characters using the proper Latin or Unicode escape sequence.

// Raw characters
var string = "ñó";

// HTML character entities
var string = "ñó";

// Escaped to Latin
var string = "\xf1\xf3";

// Escaped to Unicode
var string = "\u00f1\u00f3";

If you use the Google Closure Compiler, you’ll get the Unicode escape sequences for free (see issues 24 and 68). Make sure to read the tickets for more benefits of serving your JavaScript files using Unicode escape sequences to output only ASCII characters.

Summary

The easiest way to preemptively solve a lot of character encoding issues is to use UTF-8 for everything, and configure your web server/application to serve the UTF-8 Content-Type header. If you’re writing JavaScript code that you’re going to distribute to the masses, convert any non-ASCII characters using the proper escape sequences. Your JavaScript will be more portable, and will work out of the box on more server configurations.

Sources

1. Performance Implications of Charset, an article by Kyle Scholz

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

Updated: Added note about Internet Explorer 9 and its Compatibility View. Looks like it’s fixed!

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.

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.

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!

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'
    }));
});

Update: This script has been moved to Github.

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

YUI’s History component and Really Simple History both use setInterval with an internal variable to compare and find changes. But this isn’t really an optimal solution. As proper front end engineers, we should avoid timeouts as much as possible. Internet Explorer 8 will have an onhashchange event that clients will be able to subscribe to. That will be nice. But surely, a cross browser solution without the use of setInterval exists.

Look, a cross browser solution without the use of setInterval:

1. On initialization, we load an iframe onto the page that is positioned absolutely at -500px,-500px so the user can’t see it. It is a skeleton page that only needs cross browser code to add an “onscroll” event, and to be able to calculate the scrolled position of the iframe itself. For my example, I use jQuery and the dimensions plugin to accomplish this, but it could easily be trimmed down to only the bare essentials (or ported to a different library).
2. To add an AJAX history entry into the browser’s history under an assigned hash string, we first add a <a name="hashString">hashString</a> to the <body> tag of the iframe. Using css to increase the size of the a tag proportional to the iframe’s height, we can guarantee scrolling will happen.
3. Then, we change the location.hash of the iframe to point to that <a> tag. This will scroll the iframe to the content, and create a new entry in the browser’s history object.
4. Inside the iframe, we have our onscroll event that fires when the scrolling in the previous step took place. (Minor IE-related workaround: The browser’s history object is changed, but the hash property doesn’t when attempting to read it later. Instead, we find the <a> that matches up with the scrollY/pageOffsetY property inside of the iframe, and retrieve the matching hash from the <a> tag.)

The nice thing about this approach is that you don’t even need a history manager anymore. This little iframe will do all of your dirty work for you. And it will even maintain your history alongside any other iframe browsing on the page.

Advantages:

• Can serve as back button support and full AJAX history manager.
• Page Weight: the test page and iframe HTML files together weigh in at 2.76 KB. That includes the non-jQuery JavaScript needed to do everything.
• Cross browser: Tested in FF3, IE7, IE6, Opera 9.5, (not Safari — see below)

Limitations:

• No bookmarking support. We aren’t changing the top hash, we’re changing the iframe hash, so these aren’t bookmarkable.

Sample Example:

• My Test Page
• Download the test page (2 HTML files, and jQuery 1.2.6 and dimensions)

Update: Given time for more rigorous testing, it doesn’t look like Safari supports this approach. So, until WebKit fixes #9166, we’ll have to stick to timers in Safari. A more pragmatic programmer than I might hack around this approach by exploiting #19202, but that certainly wouldn’t be a long term solution. I’ve also updated the test page above, at Dean Edwards humble request, to support dynamic client size text size changes.

Super Fast Beginner’s Primer

• Case 1: Node (or un-namespaced node, null-namespaced node): a node without a prefix, such as child here:
  <child/>
• Case 2: Default namespaced node: a node without a prefix, but a parent node (or itself) has a xmlns attribute, like both root and child here:
  <root xmlns="http://example.com/"><child/></root>
• Case 3: Namespaced node: a node with a prefix, and a parent node (or itself) declaring a xmlns with that prefix attached, like both child and root here:
  <prefix:root prefix:xmlns="http://example.com/"><prefix:child/></root>

/End Primer

Parsing XML in the browser can be a tricky beast. There are many different wrong ways to do it, which can leave you cold and naked in a snowstorm if you’re not careful. So, let’s put on the metaphorical electric one-sie of standards based code and let the power of Edison heat our JavaScript code like the innards of a tauntaun.

If there is one thing you can take away from this article, its that the problems with XML in JavaScript have already been solved, and there is library code out there to do the job for you. But libraries aren’t a substitute for knowledge (abstraction is a dangerous thing during education), so let’s learn why these problems are occurring so we can wrinkle our gray matter and increase our productivity at the same time.

Use Cases

These are the main use cases that takes place when selecting a node inside of an XML document:

1. Case 1: Selecting un-namespaced nodes (or nodes in the null namespace):

   <root><child/></root>

   This one is easy. If you can guarantee that your XML will never have any namespaces, you’re home free. Take your get out of jail free card and run for the hills. Using this assumption, you can query nodes inside of your XML Document object using nothing other than getElementsByTagName(). Lucky bastard.

   // assume oDocEl is the documentElement inside of an XML Document 
   var correctForCase1 = oDocEl.getElementsByTagName('child');

2. Case 2: Selecting default namespaced nodes:

   <root xmlns="http://example.com/"><child/></root>

   Tread lightly, this is about to get serious. In most cases, historically I had thought that using the solution described for Case 1 would be sufficient in this case. I had learned awhile back that Internet Explorer treats node names (including namespace prefix and local name together) as one string. So, the method for Case 1 should work for Internet Explorer, especially in the case of node sans prefix. In Firefox, you’d have to use getElementsByTagNS(), but that would be just a simple wrapper.

   Then I met an Internet Explorer exception. The only unique thing about this installation of Internet Explorer 7 was that it had MSXML 6 installed, when all the other computers I had tested on were using MSXML 3. The obvious conclusion here is that MSXML 6 won’t select child nodes for Case 2.

   var incorrectForCase2 = oDocEl.getElementsByTagName('child');

   Here’s the right way to select nodes for Case 2. Fair warning, to keep the code examples here simple, this solution requires Sarissa (sarissa.js and sarissa_ieemu_xpath.js) to be included on the page prior to usage.

   // assume oDoc is an XML Document object.
   oDoc.setProperty("SelectionNamespaces", "xmlns:whatever='http://example.com/'");
   var oDocEl = oDoc.documentElement;
   var correctForCase2A = oDocEl.selectNodes('whatever:child');
   var correctForCase2B = oDocEl.selectSingleNode('whatever:child');

   Note how we’ve mapped what was the default namespace (without a prefix) to be a namespace WITH a prefix during the node selection.

   It should be noted that when the resultant XML has a namespace attached (Case 2 and 3), Firefox works fine using getElementsByTagNameNS. IE doesn’t include support for that method, however, so we’re forced to find a more complete solution.

3. Case 3: Select a non-default namespaced node:

   <root prefix:xmlns="http://example.com/"><prefix:child/></root>

   As I mentioned in Case 2, normally (pre-MSXML 6), you’d be able to perform a getElementsByTagName('prefix:child') in IE and use getElementsByTagNameNS in Firefox as usual. But that has changed now. We need to set up the SelectionNamespaces property for IE, and we’ll use Sarissa to take it cross-browser for us.

   // assume oDoc is an XML Document object.
   oDoc.setProperty("SelectionNamespaces", "xmlns:whatever='http://example.com/'");
   var oDocEl = oDoc.documentElement;
   var correctForCase3A = oDocEl.selectNodes('whatever:child');
   var correctForCase3B = oDocEl.selectSingleNode('whatever:child');
   // Note, this is the same code as Case 2 (which is a good thing)

   Note that we did not have to use the same prefix that was defined by the result XML. We can map it to whatever we want (literally).

Why is this important?

Because most libraries don’t handle Case 2 and Case 3, which are important parts of XML. Here’s some code straight from YUI 2.5.1 (DataSource component):

// Line 1394
var xmlNode = result.getElementsByTagName(key);
if(xmlNode && xmlNode.item(0) && xmlNode.item(0).firstChild) {
    data = xmlNode.item(0).firstChild.nodeValue;
}
else {
       data = "";
}

Notice how they just do getElementsByTagName. For shame :( jQuery doesn’t handle Case 2 or Case 3 either. (Proof is an exercise to the reader :P) So, if you have XML data sources with namespaces, it would do you well to use the solution presented in this article, or you’re going to have headaches later.

Springer’s Final Word

Don’t use getElementsByTagName. If you do, PLEASE include a note saying that your code isn’t going to support namespaced XML. Branch your selection code to check if Sarissa has been included on the page, and use Sarissa for namespaced XML if it’s there. It’s not fun to be pidgin-holed into the simplest case of XML.

I know this has been posted a few times before, but this is not something I knew until recently, and after learning it, have noticed quite a few other people doing it wrong as well. So, to risk adding another reverb to the echo chamber, I’ll post a link to a good explanation by Jesse Skinner on the specifics of the JSON specification.

The main point here is that all object keys and strings in JSON must have double quotes. I encourage you to look through the train track specification to verify for yourself.

If you try to use Captain Crockford’s JSON Parser, it won’t parse your string with single quotes or (un/single)-quoted object keys. His parser has a nice regex checker built-in (and a walker callback to let you parse date strings into Date() objects). It’s a good way to verify that external data, or a data source not under your control, is safe to eval and use in your own code.

Here are a few quick examples:

Valid JSON

{"myKey": "myString"}

Don’t use single quotes. Don’t use unquoted object keys.

Invalid JSON

{myKey: "myString"}
{'myKey': 'myString'}

Credits to Jonathan Snook for the initial write-up and Crockford for formalizing JSON.