James Gregory

The title pretty much covers it, but i’ll elaborate.

A few days ago I decided it was about time I had a tinker with Google Sitemaps, part of which involves uploading a temporary file so google can be sure the website you’re trying to claim is actually yours. Anyway, fun things aside, google gave me an error message (“We’ve detected that your 404 (file not found) error page returns a status of 200 (OK) in the header.”) when it tried to read the file.

I apparently got around to reading Coding Horror a bit too late, as I missed this gem. It’s an article about a small application used to bend XP’s IIS to your every whim, perfect for those of us suffering at the hands of Microsoft.

The basic gist of the application is that it removes the limits of XP’s IIS, namely the problem of only being allowed one website and 10 concurrent users. It takes a bit of getting used to, especially if you’re using Visual Studio; if you are, remember to reset IIS to it’s default website before opening a website created prior to using IISAdmin.

Handling events from within your page has always been a hit and miss affair, especially for somebody who doesn’t like mixing their code and markup. The way to go with events for a long time was to embed an attribute on the element in question; like onclick="do_something()".

That works fine, but we sure know it isn’t semantic. The way forward — greatly popularised by the Prototype, Dojo and Behaviour libraries — is to use DOM compliant event listeners. These fire arbitrary code, in a very similar way to attributes, when an event is raised. Unlike attributes these event listeners can be hidden away in their rightful place, the document header.

Perfect - clean semantic markup and real event handling.

…or is it? Unfortunately nothing is ever smooth when dealing with standards (it’s hard to promote the underdog when the underdog barely works anyway…).

ASP.Net has an interesting way of handing the potential ID conflicts caused by embedding third-party controls within your web-page; it prefixes any sub-controls with their parent’s ID.

<asp:TextBox ID="txtUsername" Runat="server" /> within a standard page simply has an ID of txtUsername within the HTML output. On the other hand, the following example would result in something along the lines of _parent_txtUsername as the ID:

<div id="parent" runat="server">
  <asp:TextBox ID="txtUsername" Runat="server" />
</div>

This isn’t really much of a problem when all you are working with is server-side code, but when you start tinkering with JavaScript, things become quite annoying and get an overall feeling of hackiness.

Behaviour, great bit of JavaScript!

While using it lately I came across a small bug in the code it’s based-on, Simon Willison’s getElementsBySelector(), when you use a selector that references an invalid ID paired with a tag name (e.g. body#profile, when #profile doesn’t exist), a script error occurs; yet using #profile alone works fine.

After a little bit of digging I found a solution, the source of the error is line 89:

if (tagName && element.nodeName.toLowerCase() != tagName) {