arantius.com

What IE7 JavaScript Needs

2006-05-03 13:55 - Programming

Venerable JavaScript guru PPK recently blogged about JavaScript in IE7 needs. We know that CSS is getting the love in IE7, but it would be nice to have JS fixes as well. So, what should we fix? Here's what I think, in no particular order. Some have been mentioned before, some not. This is just what I have managed to think of.

• "Native" XMLHttpRequest, a'la Firefox and other standards compliant browsers.
• Remove document.all. Perhaps, solve this migration issue like Firefox did (yes this will come up a lot), make it "work" if used, but return false if tested for.
• W3C style event listeners. Use addEventListener, not attachEvent. Again perhaps both, as a migration step, so old sites don't break so poorly.
• Error reporting! The dialog in IE that reveals errors is so non-helpful, it's painful. My "favorite" complaint is that it reports the line number, but not the file. That doesn't do much good, and the vague errors just make it worse. It should probably be (broken record...) like Firefox. More or less invisible to the end user, but very detailed for the developer that looks at it.
• XPath. Especially if the syntax is identical to that which other browsers (*cough* Firefox *cough*) use. I've found it to be very useful when writing Greasemonkey scripts, but never used it in a web page, because IE doesn't have it.
• Syntactic sugar. There's a number of useful things, various methods and properties, that technically I know exist but .. I can't even remember them; I've trained myself to avoid them because I can't actually use them, since IE lacks support.
• Long bookmarklets. Why the 508 character limit on bookmarklets in IE6? That should go away.
• Attributes on elements. This may be a general "good DOM implementation" that many commenters on the linked article referred to. Using setAttribute and getAttribute don't operate as expected in IE.

Anyway, that's what I can think of for now!