Some JavaScript Thoughts
I’ve had a heavy JavaScript workload for a while, and these are some thoughts/observations.
There are certain attributes whose JavaScript property names differ from their HTML element names. This is important because you can refer to an element’s HTML attributes as properties in JavaScript by doing things like element.style = "background-color:black;" to set the value of an element’s style attribute. When you run into the attributes that don’t follow this rule, it can take a while to identify the problem and find the solution if you don’t know it already.
The first such attribute/property is class, which is className in JavaScript. That’s not too bad, and you run into it more or less as soon as you read anything about manipulating the DOM with JavaScript. The second, however, is the for attribute of the label element. for, like class, is a reserved word in JavaScript, so it makes sense that it wouldn’t work. But what does, then? You could try element.setAttribute("for"), but that doesn’t work in IE. What does work, in IE and Firefox and I assume/hope other browsers, is htmlFor. That’s the name that was chosen for the property (so why isn’t className htmlClass?). for maps to htmlFor—and it took me a while to find that out.
For whatever reason, the type of a button element is read-only in IE. That makes no sense to me, but do button.type = "submit"; and you’ll get an error in Explorer. I haven’t tried setAttribute() instead, but if that does work then it makes even less sense. Am I missing some reason that type shouldn’t be set by JavaScript? In my use case, it really needs to be, since I’m creating the entire element using JavaScript. If I have to, I suppose that I can use the innerHTML property, which can be really useful despite being non-standard.
Speaking of which, one place I find myself using it is where I’m loading text that may contain markup from somewhere else—the contents of an XML node, for example. I think that the other option is to use a DOM Parser to parse the (string) contents of the node into a DOM, and then insert that with element.appendChild() instead of using element.innerHTML. That seems somewhat heavyweight to me for what “feels” like it should be a simple task, but I’ll have to look into it.
When trying to walk the DOM of an XML tree, I found an incompatibility between IE and Firefox (shocking!) about how to get the first child of the root element (or, how to refer to the root element at all). For Firefox, I used targetNode = xmltree.documentElement.firstChild;, but that didn’t work in IE, where I had to use targetNode = xmltree.firstChild.firstChild;. That hung me up for a while.
Speaking of IE, this week’s random IE bug is: radio buttons that are created with JavaScript appear to be unclickable. You can hit them (or their labels) with the cursor, but they just won’t go into “on” mode. It works fine in Firefox, naturally. I had to leave that one behind and move on, but at some point I hope to figure out what’s going on there.
21 Mar 2007 at 04:48
Re: Your random IE bug — I remember running into that myzelf a while back. Assuming your issue is the same, this sums it up pretty well.
Unfortunately, it means lots of browser-specific suckiness.
21 Mar 2007 at 09:29
Thanks for that link, Frank, it’s rather useful indeed—and yes, that is the same issue as far as I can tell. I’ll tinker with those solutions and see if I come up with anything I like.