Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for How IE7 Can Avoid Irrelevance

Hey, this is thoughtful feedback. I appreciate it and the reasoning behind it. I want us to address these issues faster too. Happy to discuss with you more in email.
by Dean at
Hi Dean, thanks for taking the time to reply.

My email address is I look forward to continuing the discussion.

by alex at
Hear hear.

Personally I'd rather see them going with standardized technologies then their own, but I'd settle for any fix.

by Marko at
Well written overview, Alex!

The most important point for javascript developers currently IMHO is:

"Today, allocating more than 5K objects or so brings JScript to its knees. Object allocation cost needs to be O(1)"

There is no real work-around for all these complex object-oriented javascript APIs.

Dean, if you're still following the thread, I'm *still* looking forward to continuing the discussion with you (via email or not).

Looking forward to hearing from you.

by alex at
The sad part is that the CSS community will most likely cheer MS for improving IE where the programmers will continue to cry themselves to sleep over annother IE version causing them nightmares.

After trying one of later Vista builds I realized that close to no work has been done regarding DOM bugs and missing DOM features.

Don't get me wrong, I also want the CSS bugs fixed but IE is bound to go the Netscape way if noone starts fixing IE-the-platform.

"programmers will continue to cry themselves to sleep over annother [...] version causing them nightmares"

Erik, please God you're wrong.

However (and whilst I appreciate that this is a preview of IE7 Beta2 and not actually IE7 Beta2 itself), those of us custom-hosting the Windows web browsing platform - and all of our OEM customers - are becoming understandably concerned that some seriously problematic issues arising from new IE7 features that were flagged to the IE team as much as four months ago don't appear to have been addressed yet.

We have to be assured that the 'real' Beta2 will show some genuine progress in that respect.

> At a minimum, dynamic web apps need the following out of IE and JScript in the very near future:

You're presuming that all future dynamic web apps should/will be built using JavaScript. Why not Flash or something similar? That bypasses the multi-browser compatibility hurdles entirely.

Hi Jeff,

I'm not presuming that dynamic web apps in the future should be built with HTML+JS, just that they will. You see, once you abandon HTML, CSS and JavaScript you're no longer developing a web app, you're developing an app that happens to use HTTP as a way of negotiating content transfer and the browser as a nice plugin platform. That's not a web app.

My point isn't to be glib, it's that the web succeeded because it was text on the wire that could be inspected by everyone and easily produced. Love it or leave it, that's an advantage that Flash just doesn't have. Open by default beats closed by default, not perhaps instantaneously, but in terms of rate of improvement. Losing "textuality" is something whose cost is felt at every part of the development and deployment cycle. HTML, CSS, and JavaScript aren't going away.

Now, I know all about MTASC and the new tools that are opening up Flash as a programming platform, but that doesn't change the fact that it's controlled by a single vendor and only renders in a single client.

The siren's song of closed platforms has been with us as long as the web has. I expect that will always be the case, and I sincerely hope that Adobe will continue to make Flash accessible to scripting in the browser. But the apps I work on, the one's that will continue to define the web, will be built with some combination of HTML, CSS, and JavaScript.


by alex at
It's always nice to suggest improvements and some of the items on your list could indeed be worthwhile - such as fixing memory leaks. I'll list your worthwile suggestions first:
  • Memory leaks need to simply disappear
  • Fix the cache+gzip bugs
  • Either revive (and start to fix) VML or give it an SVG-Tiny+DOM facade

These 3 suggestions make sense and would be nice-to-have, though none of them are the disasters you make them out to be.

However, the rest of your suggestions either make no sense or have absolutely no relevance to IE:

  • Give us getters/setters in JScript or give back watch()

IE never had watch(), Netscape did - and still has, as part of all its DOM 0 proprietary extensions. Getters would be nice but would require a thorough upgrade of the JScript engine itself. In that case I would prefer to see the ECMAScript 4 compliant core of JScript 7 inside IE, as is currently used in JScript.NET. IE already has the equivelant onpropertychange.

  • Fix the event object. Pass it in to DOM handlers by default. Also, offsetLeft and offsetTop are so ambiguious as to be useless. Give us currentTarget.

Wow, talk about mixing subjects. Eradicating the global Event object and passing it directly to DOM handlers by default will break a lot of old code, not to mention that it would have to be a completely new Event object that conforms with the W3C DOM ECMA bindings. offsetLeft and offsetTop are actually so meaningfull that all other modern browsers implemented them as well. Instead of currentTarget IE simply uses srcElement/toElement. Put simply, the non-W3C event object in IE only requires one line of additional code to work interoperably with the W3C event object using something as simple as object detection. There's no pressing need to change this.

  • Bump the limit on the number of concurrent HTTP connections if those connections are initiated after onload (either via XMLHTTP or other methods)

The number of concurrent HTTP connections after onload is the same as before onload. Bumping it up will break the HTTP standard. IE behaves the same here as all other browsers, allowing local system administrators to break the HTTP standard if they so desire but defaulting to obeying the sensible HTTP standard.

  • Today, allocating more than 5K objects or so brings JScript to its knees. Object allocation cost needs to be O(1)

Clean up your code, use proper prototyping, remove your DOM-binding closures and stop using eval. I've got no problems with either performance or memory when creating more than 100K objects in JScript.

  • Give us a persistent, string-keyed, local cache in the MB range (5-10MB/domain seems a good start)

IE already has this with the userData behavior, even allowing you to store complex XML documents. No other browser has an equivelant.

  • Fast DOM queries. CSS selectors or XPath, we don’t care. Just give us a way to say “get us all DOM node objects matching thisâ€?

Google for "ie xpath" and you'll find a host of XPath implementations for IE, or simply write your own CSS selector - my own getElementsByClassName is less than 800 bytes.

  • A way to toggle the box model on a per-element basis without switching doctypes. The CSS 3 box model spec seems a good starting point

We can start bitching about the lack of per-element box model switching when other browsers even start considering whether to implement this feature as well. In the meantime, both IE and all other modern browsers will let you switch box models on a per-document basis, which means you can use an IFRAME as a dynamically positioned container with ease. Alternatively, use a box model script which will automatically implement the changes for you or simply start writing W3C box model compliant code - IE6 has no problems with this.

In all, you have 3 nice-to-have suggestions and 10 irrelevant ones. I doubt this list is a defining factor in making IE7 irrelevant.

Hey Thor,

Haven't seen your name much since I stopped doing security for a living.

As for your comments:

I'm very well aware that the HTTP spec defines a 2 connection limit. That doesn't make it any more useful. Low-latency data transport to the browser is something that ties up a connection and multiple windows using the same technique can essentially "hang" the browser today. We need a better solution.

The 5K object problem isn't code. It's data. All the code I write uses "proper prototyping", etc. That your apps aren't large-scale enough to hit this limit is no reflection on the quality of JScript as an implementation.

Last time I tried userData, it was buggy. It's a good start, but it needs significant work for larger data sets (IIRC).

As for "getElementsByClassName", it's not the implementation that's the issue, it's the speed. Recursive DOM traversal is brutally slow from script, in part, because the JS object facades aren't created until the controls are visited the first time by a script. The browser already has a list of matched nodes for any selector in the document. Forcing us to jump through even 800 bytes to do the same thing (slowly) and w/o the benefit of a live collection is dumb.

As for the box model, you're wrong about other browsers. Opera provides "border-box", Safari and Konq provide "-khtml-box-sizing" and Mozilla exposes "-moz-box-sizing". These all allow the specification of border-box sizing on a per-element or per-sub-tree basis. IE is significantly behind in this regard.

What you consider "irrelevant" seems to be mostly informed by a lack of experience dealing with large data sets in the browser and deployment-time optimizations for large-scale apps. I realize that some of the things I'm requesting are (today) esoteric, but they are certainly not unheard of and they are growing ever more common.

As always, it's great to hear from you.


by alex at
Thor Larholm: All other browsers support box-sizing. This was something Microsoft invented in IE Mac because even back then they realized how important this is.

Implementing getElementsBySelector or XPath on top of DOM using JS is just slow (even when using a static snapshot).

JScript 7 - I'd rather have JScript 5.7 which is compatible with JavaScript 1.6. Using JScript 7 in the browser would be pretty useless since no other vendor support this and it is a step in the wrong direction (JScript 7 will never be compatible with JS2, or the other way around if you prefer).

Passing the event object to event handlers would not break anything. Removing the global event object might though, but no one suggested doing that as far as I can tell.

Erik: the following code will break (in IE) if you start passing the event object to handlers set through el.onevent.

function myFunc(myObj) { var mySrc; if (myObj) mySrc=myObj; else mySrc=event.srcElement;; }

/* Sometimes called like so: */ el.onmyevent=myFunc;

/* And sometimes like so: */ myFunc(mySource);

No, this isn't graceful or well thought out code, but it's out there. And starting to pass the event around will certainly break existing code (this is most likely why MS decided against doing it when they could have easily added it once they added attachEvent, which does pass the event object).

Alex: I just submitted this comment and after submission was told that I was missing some required fields. Using the back button destroyed my comment. I realize this has more to do with your choice of blog software than with you. But I'd fix it to use client-side validation. Without fiddler and re-submission I would have lost my comment.

by yn at
Although I am a FireFox fan and, at the risk of a flame war... I am in the process of developing a compact AJAX library and the only time I ever need to build a workaround is for FireFox - IE does what I want every time. Examples: 1) XMLDom.selectSingleNode - Arguably the most intuitive and common way to access DOM elements -not supported by FF. I know this is a MS extension but that's not a reason to exclude good features when building the worlds best brow... 2) Output escaping : The "disable-output-escaping" attribute in XSLT allows one to pass and render HTML (non XHTML) in an element. Firefox escapes it and leaves you with a mess. C'mon, this is like the core of AJAX - rendering XML elements as HTML. 3) Verbosity - What IE does with XMLDom.transformNode(XSLTDom), requires several lines in FireFox.

OK, IE has several irritating bugs but my point is, FF has some irritating "features".

by Jack at
I knew I forgot some: 4) Getting the XML text from a DOM. In IE this is simply XMLDom.xml but in FF you need to create a new XMLSerializer object and call... 5) Event object. The window.event object in IE allows easy access to things like the srcElement and keyCode. Not available in FF. I'm sure there's somthing better though...
by Jack at
Interesting arguments.

How about first off - browsers need to conform to DOM Level 1,2,3

Certainly to say "IE already has this with the userData behavior, even allowing you to store complex XML documents. No other browser has an equivelant" is a good bragging rights game, but how about I ask this differently:

Because you are implementing these items which are then IE specific, you are saying to the developers: here are some neat toys, but now you have to write 2x as much code to support other browsers. And developers can't simply ignore a population of browsers and exclude them.

Aspire to the DOM model, IE should use the DOM model. And the consumers (ie. me) will see when you are not and try to hold you accountable to that.

Jack - the reason why 'not available in FF' is because Mozilla, Firefox, Safari, Opera, etc... follow the DOM with regards to the Event object, and IE does it totally different. Thanks to IE we get to write two sets of code.

FYI - I'm a developer who works with Microsoft products. So, it's not about 'Microsoft' here, it's about following the DOM, achieving DOM level 1,2 and aspiring to DOM level 3 rather than the continual injection of proprietary browser API's.

by Steve at

No SVG - no use. This is the open standards era. SVG is the best open standard for web graphics. Don't tell me it's possible to write mobile phone firmware that renders SVG, but MS has not been able to do so in 6 years. They are purposefully (and for their own gain) not supporting it, and many other open standard technologies. They are not coming to the table, because it doesn't suite their agenda. It has nothing to do on whether they can or can not support SVG and other great technologies. I think it's time to stop supporting browsers that don't play by the rules.

To me it's simple. I'm writing basic versions of my sites to support IE, and real sexy ones that use open standards. If users want to use the good looking sites with slick functionality, then they need to use Opera, Firefox, Safari or any other browser that knows the game.

Stunning post Alex!

Stop being so pompous Thor. Anyway, you've got your money on the wrong horse my friend.

Interesting times!

by Jacobus at
I would LOVE it if IE would support setAttribute correctly.  I'm working on a projct now that uses setAttribute to define onmousedown and onmouseup for dragging and dropping.  My code is now broken in IE, because of the inability of IE to setAttribute for events.  Even worse is that IE7 doesn't even report an error.
by Ray Hauge at
I agree that IE should be fully compliant with CSS2 & DOM 1,2,3 etc. And IE's event model just sucks. I'm haveing to do eval to get around some IE bugs. for example in IE you can't call < scr ipt > var str = 'onclick; element.setAttribute(str,myFunct) </ scr ipt > instead I have to eval('element.'+str+'=function() {'+myFunct+'}') Also I hate how when writing a function to get text of a node that IE uses one reference for XML DOM and a different one for HTML DOM (element.text vs. element.innerText. The standard element.textContent is not supported by IE. Those things aside - I really hate how Opera, FireFox, Mozilla and non-IE browsers make nodes out of #text when it is just a \n or some whitespace - grrrr.
Of a truth, microsoft IE development team should sit up and take those burdens off our shoulders.
by owusu at
Standards and more standards.  I say they need a whole rewrite.  They claim they fixed transparency . . .  Now all my websites need to have a specialized css and js file for ie6 and ie7 hacks.
by mel at
came across this article while trying to find a way of debugging AJAX requests in IE.

AJAX request executes but then gives nothing for the onComplete, can't even get an alert there and no errors pitched :-/ No I have to download a 300mb package to debug javascript in IE (VWD, ok I did get the SQL Server debugger too) when firebug is all of 400K?

I used to have more patience for IE but now hold it in the same regard as NutScrape 4.*

Would rather just see IE die than continue a few more years of half assed measures and pointless grief.

Bill should give up the charity work for a year and just focus on making some decent software instead of dysfucntional bloat ware.

What is interesting is the fact that the object creation leakage talked about often seems to be fixed.
by Sohbet at
MS still doesn't seem to understand that following standards (not the one's the made up) would only help them. Every developer I know cringes at the thought of having to 'fix' their code to make it work in IE, when it works just fine in every other browser.

Add on to that some of the other 'little' problems MS creates. For example, I'm writing a dojo application, works great in Firefox, but I get a simple error in IE7. Yes I unchecked 'Disable debuggin' but still can't debug. I use the menu to 'Find more add ons' so i can, but that takes me to IE8 add-ons. Am I using IE8?? No. Ok so we'll search for some on google, and when find some they have to be paid for!

MS has to change alot if they want to slow their loss of market share.

by Jake at
ok I found the debugger, which is just aweful, but free.

by Jake at