> What problem(s) have you found with running "a web app that was built for a modern browser" on IE8?
Just take any project dependent on something on the list in the original article, and implement it on IE9.
But there are also a number of things like rounded corners, transparency, and event handling that are irksome. Thank God for jQuery. Seriously.
> As I see it, the blame for this lies almost entirely with Mozilla, Google, and to some extent the standards bodies, not with IE.
Different experiences, I guess. The last major web app I wrote (last year) ran on Safari, Chrome, and Firefox, on Windows, Mac, and Linux. No browser detection was required. IE8 and below were simply too feature-poor to even begin to run it (start with missing canvas, and work from there). Maybe no IE9-specific code will be required to run it--we'll see.
When I read your last sentence, though, I see "the problem is with everyone else, not IE". And that's definitely one perspective.
> Just take any project dependent on something on the list in the original article, and implement it on IE9.
OK, but in that case, what you really mean is a web app built for browsers that haven't even been released yet. I'm sure for some people/projects that is a serious issue, but I think your characterisation is a little unfair.
> But there are also a number of things like rounded corners, transparency, and event handling that are irksome. Thank God for jQuery.
Sure, those are annoying, but as you point out, solutions are easy to come by.
> IE8 and below were simply too feature-poor to even begin to run it (start with missing canvas, and work from there).
> When I read your last sentence, though, I see "the problem is with everyone else, not IE".
Not everyone else, just a small list of specific groups whose specific rapid-release policies keep moving the goalposts. Coincidentally, those groups hold much of the market share not held by IE today, but the point isn't that IE is somehow superior to everyone else, just that I don't like the policy those particular groups have adopted for the reasons I have been giving in this discussion.
Sir, excanvas is as slow as it can get. I am currently working on a web visualization and let me take you to earth, there are two graphic libraries to plot graphs (the ones with nodes and edges, not charts) out there:
1. The distinguished Protovis (http://vis.stanford.edu/protovis/) which doesn't run on some outdated versions of IE8 (and due to company policy I can't run Windows Updates)
2. JIT (http://thejit.org/), which performs poorly (I hardly get more than 2 FPS, whereas in Firefox 3.6 and Chromium Dev it's running well, well over 15 FPS, the target I aim for).
And let me note that making my app work on IE took me two days of work. That is what IE doesn't get and why web developers are mad at IE.
It slows down the pace of amazing UX growth in the web.
> OK, but in that case, what you really mean is a web app built for browsers that haven't even been released yet.
It is true that I am pushing to the future, but only because clients are so demanding. There's a lot of stuff out there that works fine with IE6, though.
IE8 is a generation behind. IE9 should be on-par when it comes out. That big web project I did should run on it without modification, (not counting any instances where I'm out of spec.)
> Sure, those are annoying, but as you point out, solutions are easy to come by
Well, sometimes. There's a jQuery plugin for postMessage-like functionality... but it's relatively limited in data size because it uses a hash hack. Neither FF nor Chrome flinch at postMessage-ing huge amounts of data.
Just take any project dependent on something on the list in the original article, and implement it on IE9.
But there are also a number of things like rounded corners, transparency, and event handling that are irksome. Thank God for jQuery. Seriously.
> As I see it, the blame for this lies almost entirely with Mozilla, Google, and to some extent the standards bodies, not with IE.
Different experiences, I guess. The last major web app I wrote (last year) ran on Safari, Chrome, and Firefox, on Windows, Mac, and Linux. No browser detection was required. IE8 and below were simply too feature-poor to even begin to run it (start with missing canvas, and work from there). Maybe no IE9-specific code will be required to run it--we'll see.
When I read your last sentence, though, I see "the problem is with everyone else, not IE". And that's definitely one perspective.