rahji.com: going from perl to php

Ah, the joy of finding what you need when you need it: rahji.com: going from perl to php

is the DOM ready yet?

This post ( Order of Events @ dean.edwards.name) addresses the need for a better solution than window.onload for DOM scripting. window.onload only fires after *all* the content on a page (including images) has loaded.. which is frequently significantly after the page has appeared in the browser. Mozilla/Firefox apparenly have the little known "DOMContentLoaded" event. Very handy. Windows IE has the readyState (or, better, the also little known ondocumentready event. Take this and brothercake's domFunction and there's a cross-browser solution in there awaiting the motivated developer.

XML.com: Errors and AJAX

Client-side script errors seem to be everywhere, and no-one either knows about them or takes them seriously enough to fix. This article (XML.com: Errors and AJAX) proposes a solution (and supplies js code and a sample perl backend) to catch and send errors back to the server. (Of course one irony is that of all things that can go wrong, an XmlHttpRequest implementation is likely to be up there.) The premise is that you include this file or code block on every page of a site (after testing thoroughly). That way if future script errors are introduced, they will show up in your server's error logs. Anything already watching the error log will see the error (and the appropriate people can be notified, paged in the middle of the night etc.)

As web applications move more functionality to the client, the responsibility also increases. This seems like a good practice to adopt to bring some of the rigour and accountability you'd expect on the backend over to the frontend.