My first thought was that it might be some code I had recently added to a JavaScript file which was responsible for capturing the name/value pair of the submit button pressed when you submit a form (which is the only way to get that information when using AJAX to submit form data). The code worked great in Firefox, but I hadn’t tested it yet for Internet Explorer at all, so I changed it around a bit to see if maybe some of that was causing it. My debugging progressed to completely commenting out that new code, essentially bringing me back to code I knew worked in Internet Explorer 7 before, but it was still crashing!

I started to dig a bit deeper and noticed that for some reason if I commented out one of my submit buttons (my form had two buttons with the same name – used to pick between two choices… both of which submit the form), it wouldn’t crash any more – but it wasn’t submitting the form via AJAX which it should have been, so there was still a problem somewhere. Since I was able to get a bit further now that Internet Explorer 7 wasn’t crashing, I was able to determine that it was choking somewhere in jQuery, at a piece of code that quite simply just tried to toUpperCase() a string – namely the method of the form (that is, whether it was to be submitted via GET or POST).

I played around a bit and noticed that if I hard coded in (to my JavaScript code that builds the form data to be sent via AJAX) a method of “post”, that it worked fine – it didn’t like it when I tried to retrieve the method set on the form however. After a bit more sleuthing, I decided to check up on the getAttribute() DOM function which I used to try and retrieve the form method. What I found was a piece of gold buried under the usual MSDN documentation; someone had posted a comment at the bottom mentioning an obscure bug when using getAttribute on forms… At first, I was a bit excited, hoping I had found the problem but I quickly saw that the bug was apparently just mentioning a problem when you used the name “id” on an input element which I was not doing in my code. However, I kept reading the description and noticed there was an additional bit of information stating that the problem was that the name property on an input element could actually override any key word in the DOM, potentially causing odd behaviour.

I quickly skimmed through my form, looking at the inputs and what name I had assigned them, but they were all fine, however the submit buttons were named “method” – which is a DOM property for forms! The comment quickly made sense and I knew I had found the problem; the submit button was causing a problem when I was trying to get the method property from the form through getAttribute()… it was clashing with the name property from the submit button because it’s name was set to “method” and this was causing Internet Explorer 7 to crash!

The fix was relatively simple – I just renamed my submit button to something other than “method” and presto, Internet Explorer 7 now worked just fine (and I was able to re-enable my second submit button without any problems too). Well, I shouldn’t say fine since I did discover another problem in that Internet Explorer 7 apparently submits the HTML code in between<button>…</button> tags instead of the value property defined on the button element, but that was a simple work-around thankfully.

Stupid Internet Explorer

I’m talking of course about Brian Wilson’s Index DOT Html and Index DOT Css sites. I have been using these sites over the past 8+ or so years as one of my primary resources when it comes to Web Development. They document the majority of the HTML and CSS elements and properties, how they work and what browsers support them (and to what degree) – complete with browser specific tips and notes.

The sites may not be up to date with Firefox 3 and Internet Explorer 7 or 8, but the information they provide is still very relevant and still very useful. They’re always my first stop when I need to look up a particular HTML element or CSS property, and to be honest I don’t know where I would turn if they weren’t around for me to use. I suppose I owe Brian Wilson an enormous thank you for all his hard work and dedication to the sites, and I’m pretty sure that there are many others out there who owe the same as well.

Brian, thank you for two of the most useful resources available on the Internet over the past decade or so.

After doing some initial debugging, it seemed that my responseText was coming back blank – but Firebug clearly showed that Firefox was getting the full DOM document back from the AJAX POST call, so I knew something was up with how the response was being handled by AJAX. Now, I use jQuery for the majority of my JavaScript code, so I was a bit surprised to find out that there was an AJAX problem since I figured that a bug like this would have likely at least already been reported. After a lot of searching on Google however, I only turned up one result that was quite similar to my problem which had no resolution. So it looked like I would have to solve this one entirely on my own.

I did more debugging, and out of pure luck I ended up noticing that the readyState on my XHR object was set to 0, which means that apparently an AJAX call hadn’t even been made yet. I found this rather odd to see a readyState of 0 since clearly an AJAX call had been made (and returned with success). I thought about the situation a bit and figured that perhaps I should move my debugging call (I was using console.log()) up the chain a bit so I did it as the first call from my AJAX completion callback function. After doing that I noticed that it was now correctly showing a readyState of 4. This meant that somewhere down the line, something was happening to my XHR object causing the readyState to be reset… and possibly resetting my entire XHR object!

Sure enough, I was indeed correct! The problem was that I was trying to directly access my XHR object from within a jQuery animation callback which obviously uses timers. Now, here is where I speculate because the problem only happens in Firefox, but I’m guessing that the XHR object was somehow being reset or altered after some time… very likely an internal browser cache system that was purging my XHR object. My solution was to simply copy the responseText to a variable before entering in to any timer based jQuery calls (essentially, I assigned the responseText to a variable as the first call from my completion callback function). Then, from within my jQuery animation callback I simply referred to the variable I created which had a copy of the responseText. No more random blank responseTexts!

Well, I’ve since run in to a situation that using float: left wasn’t working for me (try centering a set of divs that have float: left – it’s a pain!), so I had to find some kind of way to use inline-block.  Thankfully, Internet Explorer 8 and Firefox 3 support inline-block now, but we still have to deal with those hard-headed users that take forever (or never) to upgrade their browsers.  To accomodate Internet Explorer 7 and Firefox 2 we have to use some CSS hacks (what else is new!); thankfully they’re not that bad (but it still invalidates your CSS… bummer).

First, you must make sure that you do not throw the browser in to quirks mode, otherwise it won’t work just right.  This means specifying a proper DOCTYPE on your document (and if you’re using XHTML, don’t include the <?xml … ?> tag at the top).  Once you have that out of the way, it’s just a little bit of CSS to add to the element(s) you want to display as inline-block:


display: -moz-inline-box;
display: inline-block;
zoom: 1;
*display: inline;
vertical-align: top;


The first line sets a special Firefox property that we need for Firefox 2. The second line obviously sets the display to inline-block (and Firefox 2 will ignore this setting since it doesn’t understand inline-block). The third sets an IE-only property called zoom to a default 1 (no zoom) which triggers a switch in Internet Explorer 7 to enable hasLayout which allows the divs (which are block elements by default) to inherit inline display features. The fourth line re-sets the display to inline for Internet Explorer 7 to get the final effect we’re looking for. The last line fixes part of the word spacing problem we’re about to mention below.

As mentioned, there’s still one small problem which you may notice – inline items get word spacing applied to them because they’re now inline elements. That means that any space between your div tags will show up in your layout (even newlines!).  If you’re trying to get your div blocks to sit side by side without any spacing, you’re probably pulling your hair out because of this spacing.  There’s two fixes for it – the first is to simply get rid of it, though this usually means killing any readability in your back-end programming (if any is used) and mushing all your HTML code together in to one long line which sucks too.  The second way to fix it is with a bit more CSS around the container in which all these divs are in:


word-spacing: -1em;


That line of CSS sets the word-spacing to -1em, which is like doing a backspace of 1 character to get rid of the blank space caused by any white space or newlines between your divs. The vertical-align: top CSS we already added to the individual divs gets rid of the spacing between the divs above and below, but it doesn’t fix the spacing to the left or right. By adding a negative word-spacing, we get rid of the spacing on either side of our divs which gets rid of the last of our problems.

There you have it – a cross-browser inline-block CSS solution, and even a fix for any erroneous spaces in your HTML markup that you probably won’t want either. I haven’t tested these fixes in Internet Explorer 6 for a few reasons; I refuse to code for Internet Explorer 6 any more since the browser is so old and Internet Explorer 8 is now officially released so users really should upgrade.