How IE7 Can Avoid Irrelevance

Every generation of browsers has its boat anchor: that browser which is so painful to develop for that there’s nothing professionals would love more than to see it instantly disappear from the desks of users. This is different than simply being old. Old browsers will eventually cycle oh-so-slowly out of circulation. Webdevs understand this and live with it. We’re used to pain.

What really rankles is when there’s no light at the end of the tunnel. No year we can wistfully mark on the calendar as the date when we can use feature X of the latest CSS spec (“position: fixed;” anyone?). In the last 3 years, the title of the Web’s Boat Anchor has been handed off from Netscape 4 to IE 6. Like the dreary days of NN 4.7.x, IE 6 is patched and patched again, but never to fix bugs we care about. With Firefox ascendant, MS had no choice but to restart development on IE in order to prevent it from being relegated to displaying help files in Office via an ActiveX control. The IE 7 team has shown a willingness to be candid about what they will and won’t fix, and that much is commendable. Unfortunately, developers of dynamic applications (*cough* Ajax) have been entirely left in the cold. If Microsoft doesn’t commit to fixing the following issues in the near future, no number of CSS rendering updates are going to stem the tide. The problems on the list are by no means simple to address. In some cases, they may require re-architecting large tracts of IE internally. Here’s a little hint to whoever is the PM in charge of the renewed IE 7 effort: we don’t care. We don’t care how much it costs you. We’ve been cleaning up your messes for *years*. Those of us tasked with “just making it work” have spent so many sleepless days and nights routing around IE brokenness that our empathy and sympathy are entirely tapped out. All that’s left is a combination of despair and loathing. You want us to give a (expletive) that you blog and are “engaging with the community”? Fine. Fix your (expletive) browser. That’s the bar the IE 7 team needs to hurdle. I hope they’ve internalized that.

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

  • Memory leaks need to simply disappear
  • Fix the cache+gzip bugs
  • Give us getters/setters in JScript or give back watch()
  • 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.
  • Bump the limit on the number of concurrent HTTP connections if those connections are initiated after onload (either via XMLHTTP or other methods)
  • Today, allocating more than 5K objects or so brings JScript to its knees. Object allocation cost needs to be O(1)
  • Either revive (and start to fix) VML or give it an SVG-Tiny+DOM facade
  • Give us a persistent, string-keyed, local cache in the MB range (5-10MB/domain seems a good start)
  • 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”
  • 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

If Microsoft is to re-build any credibility around their browser, they need to show us the goods. CSS fixes won’t suffice this time around.

25 Comments

  1. Posted January 23, 2006 at 12:57 am | Permalink

    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.

  2. Posted January 23, 2006 at 2:40 am | Permalink

    Hi Dean, thanks for taking the time to reply.

    My email address is alex@dojotoolkit.org. I look forward to continuing the discussion.

  3. Posted January 23, 2006 at 3:02 am | Permalink

    Hear hear.

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

  4. Posted January 23, 2006 at 4:50 am | Permalink

    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.

  5. Posted January 23, 2006 at 4:52 pm | Permalink

    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.

  6. Posted January 25, 2006 at 3:28 pm | Permalink

    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.

  7. Posted February 1, 2006 at 3:17 pm | Permalink

    “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.

  8. Posted February 1, 2006 at 7:17 pm | Permalink

    > 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.

  9. Posted February 1, 2006 at 8:39 pm | Permalink

    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.

    Regards

  10. Posted February 13, 2006 at 5:23 pm | Permalink

    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.

  11. Posted February 14, 2006 at 12:17 am | Permalink

    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.

    Regards

  12. Posted February 14, 2006 at 12:29 am | Permalink

    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.

  13. yn
    Posted February 17, 2006 at 6:31 pm | Permalink

    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;

    mySrc.style.whatever=whichever;
    }

    /* 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.

  14. Jack
    Posted March 11, 2006 at 2:58 pm | Permalink

    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”.

  15. Jack
    Posted March 12, 2006 at 1:55 pm | Permalink

    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…

  16. Steve
    Posted May 28, 2006 at 5:19 pm | Permalink

    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 asp.net 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.

  17. Jacobus
    Posted June 28, 2006 at 10:23 am | Permalink

    Hi,

    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!

  18. Ray Hauge
    Posted January 9, 2007 at 12:43 pm | Permalink

    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.

  19. Posted January 25, 2007 at 10:23 am | Permalink

    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.

  20. Posted July 14, 2007 at 6:18 pm | Permalink

    Of a truth, microsoft IE development team should sit up and take those burdens off our shoulders.

  21. Posted July 23, 2007 at 12:01 pm | Permalink

    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.

  22. Posted August 23, 2007 at 11:19 am | Permalink

    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.

  23. Posted April 27, 2008 at 11:57 am | Permalink

    What is interesting is the fact that the object creation leakage talked about often seems to be fixed.

  24. Jake
    Posted July 22, 2009 at 1:49 pm | Permalink

    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.

  25. Jake
    Posted July 22, 2009 at 1:59 pm | Permalink

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

    http://www.microsoft.com/downloads/details.aspx?FamilyID=2F465BE0-94FD-4569-B3C4-DFFDF19CCD99&displaylang=en

10 Trackbacks

  1. By Keeping IE7 Relevant » Bill’s Baby on January 23, 2006 at 6:24 am

    [...] Dojo’s lead developer, Alex Russell believes that Microsoft are running the risk of producing an irrelevant browser with the forthcoming version of Internet Explorer 7. Every generation of browsers has its boat anchor: that browser which is so painful to develop for that there’s nothing professionals would love more than to see it instantly disappear from the desks of users. This is different than simply being old. Old browsers will eventually cycle oh-so-slowly out of circulation. Webdevs understand this and live with it. We’re used to pain. The IE 7 team has shown a willingness to be candid about what they will and won’t fix, and that much is commendable. Unfortunately, developers of dynamic applications (cough Ajax) have been entirely left in the cold. If Microsoft doesn’t commit to fixing the following issues in the near future, no number of CSS rendering updates are going to stem the tide. The problems on the list are by no means simple to address. In some cases, they may require re-architecting large tracts of IE internally. Here’s a little hint to whoever is the PM in charge of the renewed IE 7 effort: we don’t care. We don’t care how much it costs you. We’ve been cleaning up your messes for years. Those of us tasked with “just making it work? have spent so many sleepless days and nights routing around IE brokenness that our empathy and sympathy are entirely tapped out. All that’s left is a combination of despair and loathing. You want us to give a (expletive) that you blog and are “engaging with the community?? Fine. Fix your (expletive) browser. That’s the bar the IE 7 team needs to hurdle. I hope they’ve internalized that. [...]

  2. [...] In fact many demos of qooxdoo run much faster now in IE7 compared to IE6. And they are even faster than in Firefox 1.5 in many cases. This is a huge jump in performance. Microsoft did not tell about their exact modifications, of course. Anyway, they have fixed the major problem of large JavaScript-based web applications. This problem, despite having a catchy name, was mentioned many times before like here, here and there: If you have many objects created, which are simply accessible in the current scope, all methods and features of JavaScript slow down dramatically. Yeah, right, the entire execution speed drops significantly. No other browser besides IE shows such a strange behavior. It is quite interesting that IE6 really gets slower the larger the total number of (accessible) objects. Sure, it is logical that more instanciated objects need more memory, but it is not logical that at the same time this will dramatically reduce the performance of any code (that is not even accessing this data). [...]

  3. By Ajaxian » Improved JavaScript Performance in IE7 on September 13, 2006 at 6:54 am

    [...] What is interesting is the fact that the object creation leakage talked about often seems to be fixed. [...]

  4. [...] In fact many demos of qooxdoo run much faster now in IE7 compared to IE6. And they are even faster than in Firefox 1.5 in many cases. This is a huge jump in performance. Microsoft did not tell about their exact modifications, of course. Anyway, they have fixed the major problem of large JavaScript-based web applications. This problem, despite having a catchy name, was mentioned many times before like here, here and there: If you have many objects created, which are simply accessible in the current scope, all methods and features of JavaScript slow down dramatically. [...]

  5. By dojo.foo » dojo.query: A CSS Query Engine For Dojo on February 4, 2007 at 12:11 pm

    [...] Of course, the 80% browser doesn’t support XPath, but I’m personally over losing sleep to Microsoft’s bad engineering and management decisions. If the IE team decides to get with the program and give us a good query engine, we’ll use it. Until then, they get best effort. Their browser only deserves to look as good (or bad) as it really is, after all. [...]

  6. [...] I wrote this post well ahead of the release of IE 7, and I’ve been holding back on writing a follow up until things seemed reasonably settled. A year and a half since that post, and almost a year since IE 7 hit the streets, I fear things are more settled than anyone would like. [...]

  7. By stephenwoods.net » IE Sucks…Still on September 10, 2007 at 4:52 pm

    [...] Alex writes up the state of the art from microsoft. The word “sucktastic” comes to mind. [...]

  8. [...] Alex Russell http://alex.dojotoolkit.org/?p=536 [...]

  9. [...] – Alex Russell, How IE7 Can Avoid Irrelevance, January 22nd 2006 [...]

  10. [...] having the “currentTarget” property on the Event object in IE really sucks.  You can use “srcElement”, but it isn’t the same element as “currentTarget”.  For instance, if you [...]