Getting a button element's value attribute (not innerHTML) in IE

2008-05-23 2 min read Ie Ie8 Javascript Microsoft Eddie

After spending a small part of my evening debugging Javascript in IE (which is ALWAYS a pleasure), I found out one of my errors was a mistake I had made before… trying to access button.value in IE. IE, of course, being IE, returns the innerHTML value of the button, instead of the value attribute. Last time I ran into this, I used a class instead of value, and moved on with my life. Tonight, I was feeling stubborn, and I found a better way…

target.value = target.getAttributeNode(‘value’).nodeValue;

I’m sure I’m about the millionth person to discover this, but I couldn’t find it anywhere using standard searches, so I thought I’d try to emphasize it here so others could find it. (Hopefully it’s not so common that everyone else knows it!)

At first, I used the following:

target.value = target.attributes.getNamedItem(‘value’).nodeValue;

Then I looked at Flanagan’s Javascript: The Definitive Guide (using his amazon associates link), where he states that IE implementation of the attributes array,“makes it impossible to use this feature portably.” He doesn’t mention which version of IE (this specific line of code worked in IE6, IE7, and IE8a), but I figured I’d go with the more general version.

If you read this, I hope I could save you a bit of time.

P.S. – I used IE8a’s Debugger to help. Here’s hoping they develop it further before the standard release. It’s MUCH better than flying blind, but I can’t imagine a less helpful message than specifying an object in the console, and seeing “{…}”.

Big release day on the webbernet

So I guess it’s simply the time of year. Many big releases today… software, APIs, and more!

First, the biggest. IE8 has been released in initial beta. The release was also included a general overview of IE8’s new features and fixes. It’s actually quite a lot of information to absorb all at once. I’ve skimmed a number of the IE8 whitepapers, and feel the biggest changes are W3C’s WIA-ARIA support, Acid2 compliance, the javascript selectors api, and their assertion of achieving CSS 2.1 compliance. Of course, the devil is in the details, and there is no company for which that statement is more true. They have a lot of work ahead, and we know they talk a good game. The big upside, however, is that they are actually talking about it. Out in the open. Big step, and I applaud them for that.

The other biggest buzz of the day was from Yahoo, in announcing the beta of their Fire Eagle service, an API for broadcasting your physical location to the web. I wouldn’t call it earth-shattering, but I think that there’s a good chance a number of cool things are built with it. Watch the video of it’s introduction, and then take a look here to quickly get an idea of the details. It would appear from the details that it was written in a highly usable way.

Of more direct importance to me, Google has announced their Contacts API. I despise when sites ask me to enter my username/password for other sites. The most offensive request is for Gmail. I don’t have any interesting emails, let me tell you… but I certainly don’t want to let others read them. The Contacts API is a safe way for distribution and use of your Gmail contacts, without threatening the security of your Gmail account or your other Google-stored information. With this, I should be able to sync my Gmail contacts with my desktop mail contacts. I’m very happy about that.

Heading up the long-since-overdue category, AOL has announced they’ve opened their Instant Messenger Protocol, OpenAIM. Finally. I remember ages ago when… well, it’s all in the past now. That’s one big wall that has been broken down between protocols, and hopefully Yahoo and Microsoft will fall in line. It will be great if other apps can finally use the features that have been limited to the AIM client for all this time. I use Adium and Pidgin most of the time (Adium, I believe uses Pidgin’s core), and look forward to seeing what they do with the new open protocol. (On a personal note, hopefully this doesn’t spell any negative news for my friends who work on AIM.)

Continue reading

The IE8 doctype meta waiting game

2008-01-26 2 min read Ie Ie8 Microsoft Standards Web Eddie

The first time I played Yahtzee was… only about a month ago. I won 3 of my first 4 games. It was a fun game. I wonder how that game would be if I played against… oh, let’s say… Microsoft. Probably… not so much.

Jeremy Keith, my favorite famous-web-developer-that-I-watch-from-afar-via-his-blog (sorry, didn’t have a better term for that… he seems like a fun guy) has written a follow up post about the IE8 doctype meta mess. As I’ve come to expect, he has eloquently suggested a rational and positive approach to the proposal. As I mentioned in my last post, the meta isn’t really that terrible, while the default behavior is. Jeremy, along with others, suggest we need to politely and intelligently urge Microsoft, hoping they re-consider. This of course, is the correct course of action. Insults, and things of that nature are just a waste… life’s too short.

The problem, is that life is short. The list of things that we’re waiting on from Microsoft is long. And there is very little crossed off! We’re still waiting on correct handling of CSS. We’re still waiting on correct javascript behavior. I worry that it will be forever before Microsoft takes it’s turn in this game.

I’m all for civil discourse. This IE8 hub-bub made me instantly think of an online petition. But while I will be cheering Microsoft on, excuse me if I keep my fingers crossed behind my back. Will Microsoft make the next move? Will they pause the game and get back to it? Hopefully. My father always told me that we had a relative who would pretend to sneeze while kicking the checker board. That wouldn’t be nice, but it would be swift. A game ended by neglect may be far more painful.

Older posts