Geek Daily

Working in JavaScript is one of my favorite things to do. I love how dynamic the language is and how powerful it can be. This programming dream is often turned into a nightmare by varying browser implementations, blatant disregard for accepted Web Standards (I’m looking at you IE), and a host of other odd things that can pop up.

The Problem

As is usually the case, Internet Explorer is very forgiving when it comes to the DOM and lots of times implements alternate methods of accessing certain functionality.

In my current project I am using the rel attribute to keep track of which row of data is being accessed. I know some of you may frown on this, however, it is an acceptable (to me) tactic as this is for a closed intranet where there is no concern for search engines. In Internet Explorer object.rel is an acceptable method for accessing the value of the rel attribute of a particular property.

Somehow I worked past this point without testing in Firefox so when an error kept occurring that was caused by Firefox not liking object.rel it took me a while to work back through the code to isolate this problem.

The Resolution

The problem has a really simple fix. In my case it was harder locating the problem then actually fixing it. To get around this problem you don’t need any object detection, you just need to use the standard method for accessing attributes, object.getAttribute(’rel’). Go figure.

The Moral Of This Story

The lesson that we should take away from this is to only use approved, standard methods of functionality. This too will lead you into problems due to inconsistent implementations but at least you are doing it the right way. You can then implement your own work-arounds or use a library like Dean Edwards’ IE7 script that will fill in all the holes in Internet Explorer to make it more standards compliant.

Yes, the title is a question. I think the answer to that is yes, although I am not sure.

I encountered a very strange problem yesterday and it took a while to track down. I found this problem so frustrating that for a moment (only a brief one) I questioned my adoration for ASP.Net.

What Was Happening?

I’ll explain a little about the problem so you can understand where I am coming from.

First off I should mention that this was occuring in an old in-house CMS product that, IMO, should be tagged as legacy code. It spits out bad HTML which is mostly to blame on a rich text editor that is used to design templates and modify text on pages. The pages have a HTML 4.0 Transitional doctype.

The problem was that ASP.Net Session variables were not persisting on page refresh. They were set and could be used afterwards in the same request but when I navigated to a different page or refreshed the same page all Session variables were null again.

To screw with my head a little bit I tested 3 different browsers. IE7 and Firefox 3 had the problem consistantly but Chrome worked just fine, my Sessions stayed alive from page to page. What the…!

The Solution…I Think

I eventually tracked the problem down after more than 4 hours of going through [legacy] code, line by line. That was painful. The way the CMS works is any template tags that are unused get removed so there isn’t a bunch of useless HTML messing things up. I found however that unused image template tags were still rendering but with an empty source attribute.

<IMG ALT="" SRC="" ONLOAD="constrain()">

Notice the all uppercase…gross. Anyway, I discovered that if the unused images were removed or the src was set to ’spacer.gif’ then all was well again.

The Take Away

So, I am left amazed that bad HTML code can mess with something like ASP.Net Session variables. How is this possible and why didn’t Chrome/WebKit have a problem? My first reaction would be to blame Internet Explorer but even Firfox choked on this!

And is leaving the src attribute empty even considered invalid markup (in HTML 4)?

This is by far the weirdest thing I have experienced while using ASP.Net. Has this happened to anyone else? Anyone care to explain how this is possible?