IE Fun Fact: getAttribute of form action doesn’t work

Given the following HTML:

<form id="form" action="servlet.do">
  <input type="submit" name="action" value="Add" />
</form>

How does one get the value of the form’s action attribute? form.action is of course right out, as that returns the <input> node. But what about:

var form = document.getElementById('form');
var action = form.getAttribute('action');

Makes sense, no? It turns out that this doesn’t work in Internet Explorer. In IE, the result of the getAttribute call is still the <input> node.

The solution, as described in this forum (thx, MHenke!) is to dig into your DOM reference book and use getAttributeNode instead:

var form = document.getElementById('form');
var action = form.getAttributeNode('action').value;

And good times were had by all.

Explanation of binding in JavaScript

A List Apart has a new article about JavaScript binding. If you don’t already have a solid appreciation for the fact that the this keyword in JavaScript does not work the way you would expect from Java, it might be worth giving the article a read.

In JavaScript, binding is always explicit, and can easily be lost, so a method using this will not refer to the proper object in all situations, unless you force it to. Overall, binding in JavaScript is not a difficult concept, but it is far too often ignored or glossed over by JavaScripters, which leads to confusion.

That being said, you may need to already be comfortable with first-class functions to totally grok it.

Also, I was somewhat disappointed by the statement:

Such a closure will be maintained by the JavaScript runtime no matter what, so there is no extra cost to using it. Even if there were, I’m fairly confident that it would be far less than the cost of an extra function call at every turn of the loop.

I’m poking around now to see if I can find real performance numbers for bind() vs. lexically binding this. The words “fairly confident” are a giant red flag in any optimization discussion.

IE Fun Fact: "disabled" not supported for <option>s

Select, Option, Disabled And The JavaScript Solution: “As I mentioned recently, there is a bug in Internet Explorer that stops you from disabling options in a select/dropdown element.”

Yes, that’s right. You cannot disable a menu item in a <select> box in IE6 or IE7. The above post goes on to list some failed attempts at a solution before coming up with something that works, involving listening to onchange and correcting selections of disabled items.

Hat tip to Jason for getting bit by this.

IE Fun Fact: cssFloat vs. styleFloat

I’m a bit embarrassed that I didn’t already know this cold, but I found out today that not only is the “float” style attribute called “cssFloat” in JavaScript, it’s called “styleFloat” in Internet Explorer.

From JavaScript tutorial - DOM CSS:

The only odd style is float, which is a reserved word in many languages, including JavaScript. As a result, the float style must be set using cssFloat in standards compliant browsers, and styleFloat in Internet Explorer (some standards compliant browsers also provide this as well). Simply set both of them. It will not cause any problems, and will work in all possible browsers.

In other words:

var floatValue = el.style['cssFloat'] || el.style['styleFloat'];
el.style['cssFloat'] = 'right';
el.stlye['styleFloat'] = 'right';

How To Attack An Internet Explorer Display Bug

I just mentioned this in today’s fun fact about zoom: 1, but it’s good enough that it deserves its own post: How To Attack An Internet Explorer Display Bug.

Read the whole thing, as they say. (Executive summary: use position: relative and, if that doesn’t work, move on to forcing hasLayout.)

Fun Fact: zoom: 1 Gives “hasLayout” in IE

I only just a few days ago discovered zoom: 1, the fun fun CSS attribute hack to force an element to hasLayout in Internet Explorer. (Alternative methods are floating or using height: 1%.)

For whatever reason, my IE hammer toolbox up to this point had been limited to position: relative, and I hadn’t delved into hasLayout as a solution at all. With zoom: 1 I (and you, I suppose) now have a second “well, let’s see if this works” option for getting a hidden or mis-aligned element to appear correctly in IE.

For a good summary of hasLayout and it what it’s good for, read “On having layout.” There’s also the very good “How To Attack An Internet Explorer Display Bug” article, which is quite thorough.

Webmonkey’s Back!

Webmonkey is back as part of Wired! The monkey appears now to be jazzed up with hipster glasses, indicating that this is truly Web 2.0.

Like Google’s Doctype, Webmonkey is now fully publicly-editable. I’ll be interested if this sort of thing ends up being an overall benefit, or if the sites won’t attract the dedicated admins that will keep them from being overrun.

I remember Webmonkey from the golden years. I believe I got significant instruction on server-side includes from them, as well as the details on the proper use of document.layers.