These are both fine for most cases, but what about a situation where you have a hard dependency on the css for the javascript to work correctly? You could take a best-guess at a wait time for the CSS to load, or even set the XHR to be synchronous – however both of these are very poor for both actual and perceived performance of your page (and the former may simply fail).

When might this be the case? Let’s say you have some asynchronously loaded javascript that is intended to create a widget on the page, something like this (which assumes you are using jQuery as your dom library):

function moveLargePanels() {
    // make a panel container for large panels
    $('<div id="largePanelContainer"></div>')
        .appendTo('body');
    $('.panel').each( function(i, panel) {
        if ( panel.outerWidth() > 300 ) {
            panel.appendTo('#largePanelContainer');
        }
    }
}

And some corresponding CSS:

.panel {
    border:1px solid #000;
    padding: 20px;
}

The idea here is that, since there is some interaction between the logic in the javascript (a test for the “outerWidth”) and the styling in the CSS (setting the padding) that the javascript can only work correctly once the CSS has been loaded and applied.

This should be fine right? Start the javascript and the css loading, and have events attached to the load of each letting you know when everything is ready and it’s safe to fire “moveLargePanels()”. Wrong, or at least tricky, and essentially impossible if the CSS is loaded from a different domain to the hosting webpage.

You can get James Burke’s excellent description of this problem here:
http://requirejs.org/docs/faq-advanced.html#css
And a first pass at solving this (in some browsers) here:
http://bugs.dojotoolkit.org/ticket/5402

Burke mentions a using a “well known” style rule to test whether the style is loaded. I suggest a standard pattern for the rule, and also a mechanism for dynamically setting it.

Enter CSSP

You may have heard of JsonP – a way of serving dynamically generated JSON which is padded with a method call (the method name is supplied in the query string of the URL), which allows for cross domain loading of javascript. The idea behind CSSP is similar – it defines a pattern for loading css cross domain. Instead of wrapping in a callback though, we can use the URL query string mechanism to supply the special “test rule” that we use.

Dynamic Rule Pattern

Given this url:

http://someserver.com/stylefile.css?cssp=123456

.panel { ... }
.largePanelsContainer { .. }

/* and the special rule: */
cssp { zIndex:123456; }

So, in whatever loader we want to build, we can add something like this (n.b. this isn’t tested code):

var cssp_counter = 0;
function loadCss(url, callback, className, zIndex) {
    // create a counter for special class names, so they are unique
    className = className || 'cssp' + (cssp_counter++);
    zIndex = zIndex || 123456;
    url = url + '?' + className + '=' + zIndex;
    $('<link>')
        .attr({
            rel: "stylesheet",
            type: "text/css",
            href: url
        .appendTo('head');
    // append a dummy div to the body for the test
    var div = $('<div></div>')
        .addClass(className)
        .appendTo('body');
    // now poll for the z-index value:
    var cssp_interval = setInterval( function() {
        // if the zIndex is applied, we know the css has loaded
        if ( div.css('zIndex') == zIndex ) {
            div.remove();
            // callback:
            callback();
            clearInterval( cssp_interval );
        }
    }, 100);

}

The code above to do the loading and fire a callback is very naive. It would be much better to have an event that can have listeners added, and to have some tests and some failure management like a maximum timeout.

Default Rule Pattern

This obviously presupposes that the CSS is dynamically generated to some degree, even just by adding the special rule to an otherwise static file. I think that an alternative to the performance-conscious would be a “default” special rule, based on the css filename. This needs some thought, and could well be tied to a build-step in your deployment process (you do have one, right?). The pattern comes in two parts:

• There is a standard zIndex that is always used.
• The filename includes the “special class name” that is used within.

For example:

Given the file: styles.fhddgso9j.css

.someclass { ... }
.otherclass { ... }

/* and the special rule */
.fhddgso9j { z-index: 123456; }

The javascript to go alone with this might look something like:

var cssp_counter = 0;
function loadCss(url, callback) {
    // create a counter for special class names, so they are unique
    className = getSpecialClassName(url);
    zIndex = 123456;
    $('<link>')
        .attr({
            rel: "stylesheet",
            type: "text/css",
            href: url
        .appendTo('head');
    // append a dummy div to the body for the test
    var div = $('<div></div>')
        .addClass(className)
        .appendTo('body');
    // now poll for the z-index value:
    var cssp_interval = setInterval( function() {
        // if the zIndex is applied, we know the css has loaded
        if ( div.css('zIndex') == zIndex ) {
            div.remove();
            // callback:
            callback();
            clearInterval( cssp_interval );
        }
    }, 100);
}
function getSpecialClassName(url) {
  // get just the filename, e.g. "styles.9ufosdfij.css"
  var filename = url.substring( url.lastIndexOf('/')+1, url.length);
  // split on the "." marks
  var parts = filename.split('.');
  // assume it will be the second-to-last part (since the last should be "css")
  var className = parts[ parts.length-2 ];
  return className;
}

As noted above, this naive, untested code.

Wrapping Up

Ideally I’d like any “css loader” to use actual browser events (or properties) where possible, and to fallback on this setup as a last resort.

If I get time I’ll implement this and put the code on github. Please do get in touch if you’d like to pair on this!

• Dojo: The Definitive Guide
• Mastering Dojo
• Dojo: Using the Dojo JavaScript Library to Build AJAX Applications

All three books cover the core dojo library and dijit gui controls and also associated tools like the build system.

Dojo: The Definitive Guide

If I ever want to get a book on a subject and there is an O’Reilly Definitive Guide, I will choose that one – mostly based on having the Javascript and Actionscript equivalents. I have to say though that I felt a bit let down with this version, as DTDG isn’t as comprehensive as I’m used to from the series. While the coverage is broad (more so than the other books in this review), it isn’t all that deep in some key areas – missing out on some of the gotcha’s that I have found indispensable when working with Dojo.

I should make it clear that book is very clearly written with clean and helpful examples. It is also written with the clear intention of readers people build solid web applications beyond using Dojo.

DTDG does go into excellent detail about the Dojo environment – bootstrapping, the build system, the dijit life-cycle, browser utilities, OOP with Dojo, Event management and the Publish / Subscribe mechanism, Ajax / JSON / JSONP / JSON-RPC, and more besides. I think few people who aren’t Dojo committers could read and grok the book without gaining considerable insight.

This puts the book in context – it isn’t really for the average developer who wants to get an application up-and-running with Dojo. I would say it is for someone who wants a deeper understanding of the structure of the library, rather than how to hack something together with it. A good example is the explanation of dojo.byId(), a clear detailing of the vagaries of document.getElementById() – and why the former is more useful (however I’ll leave you to go and buy the book to find out the specifics ;).

Mastering Dojo

I would recommend this book without hesitation. I found it informative, helpful and really on-point while trying to create a fairly heavy application on top of Dojo. Written in the usual Pragmatic Programmer style, it is as easy to read through a chapter as it is to dig into for a specific answer.

Perhaps one omission is the DOH (which the book incorrectly refers to as the Dojo Object Handler) – perhaps correctly citing the fact that it is out of it’s own scope. Given that DOH is dojo agnostic (your project does need to use Dojo to be tested with DOH) I suppose that is fair enough, but I would love to have seen even an introductory chapter on it.

Mastering Dojo is structured in a slightly confusing way – confusing at least if you are used to The Book Of Dojo and it’s well worth searching for terms in the index (unless you’re reading a PDF!) when the chapter titles don’t look as though they contain what you need.

Dojo: Using the Dojo JavaScript Library to Build AJAX Applications

I’m afraid to say that I wasn’t especially enamored of this book – from its tongue-tangling and strangely-chosen title onwards. I felt that it missed a considerable amount about the basics of dojo – which is understandable given its title – without really giving enough detail or insight into building an RIA – which is not.

Using Dojo (the best shortening I can come up with) does give a reasonable introduction to dojo, and covers some of the fundamental forms of usage, but it really isn’t comparable to either of the previously covered titles.

Update 2008-07-03 : Alex Russell, one of the core dojo committers has also reviewed these books.

There were several parts to the problem:

• Iframe Transparency in IE
• Targeting the containing div node, the editor’s iframe tag, and that iframe’s body node
• Ignoring the weird default content that Dojo, or possibly the browser itself, adds to the Editor (a <br /> tag, but with a special attribute in Mozilla browsers)
• Removing the class once the user makes a change to the content

Ignoring all the rest, and a lot of the specifics (since I’m sure there are better ways to achieve all this) I’m just going to note how to get use dojo.connect to respond to a ‘click’ inside the editor area. It’s worth noting that using the normal method’s you would expect sort of work – but only when you click on the Editor’s toolbar rather than the inside the editable area. That being said, here you go:


<textarea dojoType="dijit.Editor" id="dijitEditor">Click Me</textarea>
<script>
dojo.addOnLoad(function() {
 var dijitEditor = dijit.byId('dijitEditor');
 var eBody = dijitEditor.iframe.contentDocument.body;
 dojo.connect(eBody,'click',onEditorClick);
});
function onEditorClick() {
 alert('you clicked the editor window');
}
</script>


NB – Not IE-friendly. This won’t work in IE because of the contentDocument property, which it doesn’t support – but you could use the document.frames[] array instead. Note that the iframe’s id is widgetid+’_iframe’ in all except Mozilla. So something like this:


dojo.addOnLoad(function() {
 var dijitEditor = dijit.byId('dijitEditor');
 var eBody;
 if ( dojo.isIE ) {
  eBody = document.frames['dijitEditor_iframe'].body;
 } else {
  eBody = dijitEditor.iframe.contentDocument.body;
 }
 dojo.connect(eBody,'click',onEditorClick);
});


I really went down the rabbit hole for while chasing ‘ondijitclick’ and the ‘events’ / ‘captureEvents’ properties of the Dijit.Editor, but ended up using this fairly straightforward custom method.