Know your (event) sources

A loooong time ago I wrote this tutoral on JavaScript events, in which I included a cross-browser event handling script called addEvent.

Today, Peter-Paul Koch: addEvent Considered Harmful. And he's right, you can get into all kinds of headaches using IE's attachEvent method, as my own addEvent snippet does. Be sure to read the ensuing comment thread for some interesting alternative approaches.

Caveat implementor, my friends.

PS: I'm rather pleased that something I wrote merits a "considered harmful" treatise! I'm in good company.

Firefox document.all caveat

document.all is a proprietary feature of Microsoft Internet Explorer; a JavaScript-accessible collection of all page elements and precursor to the W3C document.getElementById() method.

Firefox doesn't support document.all. Or does it?

Beware: Firefox does sport a document.all when a page is in quirks mode. In fact, you can see it with the DOM Inspector tool. It doesn't have any child elements so I suspect it's some sort of wrapper for getElementById. Try referencing it from code and you may get this friendly warning:

Warning: Non-standard document.all property was used. Use W3C standard document.getElementById() instead.

Switch to a standards-compliant page and document.all is undefined, as expected.

Obviously this puts code that employs quick old-school browser checking with document.all at risk — especially if your code is meant to be portable or drop-in. Updated: see below.

Update: looks like support for document.all was introduced in Moz 1.7.5 back in December 2004.

Update #2 Confusion. The Mozillazine note says the document.all is "undetectable", but the way I discovered this was because FF was taking an IE code path based on the existence of document.all, exactly what shouldn't be happening. So I dunno.

Update #3 I haven't been able to reproduce the case that led me to discover Firefox's document.all implementation, so I think the bug must have been in my code. (Shocking, I know!) In any case, it does look like a test for document.all in Firefox should return false.

Google Talk

Raise your hand if you were underwhelmed by Google Talk not only being Windows-only, but a desktop app. ::raises hand::

I'm sure I'm not the only one scratching my head over Google's decision to do a desktop app as opposed to a web client. It's not like it hasn't been done before — AOL's AIM Express is, as far as I can tell, a pure DHTML IM client although I can't tell for sure if it's a persistent connection or polling. Actually, I don't care; AIM Express rocks. It does the job, works in Moz, 'nuff said.

Most likely Google Talk is chained to the desktop due to it's VoIP features. Fair enough, I don't think, uh, VoIP-over-HTTP is a worthwhile endeavor right now. Maybe the IM features are just a nice-to-have thrown in on top of an app that was initially designed to make VoIP as easy as IM.

But still, kind of a strange sideways move for Google.

Here come the Ajax books

It's only been six months since Jesse James Garrett neatly rechristened the combination of JavaScript, DOM and behind-the-scenes HTTP requests as "Ajax," and there are already three books available for preorder at Amazon:

• Ajax in Action
• Foundations of AJAX
• Professional Ajax

I've also heard rumblings of books from O'Reilly, Sitepoint, etc.

Are you working on an Ajax book? Hit us with a comment.

Beware of false falses, or something like that

This is a really, really common gotcha that trips up even expert webdevs.

When you're checking for the existence of an object or property, make sure what you're testing is not going to return an unexpected value. For example.

if (document.documentElement.scrollTop) {...}

Right away, we're in trouble. Why? Because the default value of scrollTop is zero (for a page that hasn't been scrolled yet). In JavaScript (and many other "real" programming languages), zero is the same as false. So in the above statement, the conditional in parenthesis will fail, and the code will make the wrong choice — and we haven't even tested for document.body yet.

What about this?

if (document.documentElement && document.documentElement.scrollTop) {...}

Also no good if scrollTop returns zero. Here's a better way:

if (document.documentElement) {...}

This test will return undefined if documentElement is missing, which is correct behavior. In a pseudo-Boolean check like this one, undefined is as good as false.

The dark despair of DOCTYPEs

It bears repeating: the use of different DOCTYPEs can change the DOM interface in unexpected ways. It shouldn't, but it does. To wit:

document.body.scrollTop

becomes

document.documentElement.scrollTop

...depending on which DOCTYPE is used. (The former property doesn't disappear, but stops being updated, returning 0 (zero) no matter how much you scroll). This seems to be true for both IE6 and Firefox. So be sure to test for both if your web app depends on accurately measuring the scroll offset of a page. Double-especially if your app is something to be dropped into existing webpages with DOCTYPEs you cannot know in advance.

IE has a neato

document.compatMode

property that returns "BackCompat" if the DOCTYPE is allowing the page to behave like old-school IE, with the broken box model and the stuff and the thing. "CSS1Compat" indicates DOCTYPE-triggered "standards-compliance" mode. So you can have your app test for this and adjust accordingly.

IE style rule gotcha

I've been busy with massive project at the day job (launching soon, hope to mention it in detail here), and soon I'll be preoccupied with a C++ course, so I don't expect to be posting with any regular frequency here for the remainder of the summer.

I will share this, though: just because you can set style properties with a string:

elm.style.fontSize = "12px";

...doesn't mean IE will accept any old string:

elm.style.fontSize = "12px !important";
/* causes 'invalid argument' error in IE */

Firefox has no problem with this. Of course.