Hacker News Reader

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

http://excanvas.sourceforge.net/

You're welcome. :-)

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

> http://excanvas.sourceforge.net/

"I tried that. Don't you think I would have tried that?"

The solution people are using is to write a custom Flash piece that does the functionality they need specifically and interfaces with the JS.

>So people often seem to say, yet I find very few portability/compatibility issues with running my web apps on any recent browser. I was surprised to find that in the last problem that did arise, it was actually IE that was compliant and Chrome and Firefox that were implementing non-standard behaviour.

Go on ... I've come across this once before several years ago but would be interested to know the details of this?

That particular case related to escaping characters that can be significant in HTML (quotes, ampersands, etc.). It turned out that IE honoured the named entities for exactly those characters specified in the HTML4 documentation when rendering an HTML4 document, while Firefox and Chrome also translated some additional named entities that were required by XHTML but not in HTML4. When it came to filling in form content from a database via AJAX, this led to a portability problem where you had to decide what to escape and what to put in verbatim.

>also translated some additional named entities that were required by XHTML but not in HTML4

Sounds like you were passing non-allowed entities into a doc interpreted as XML but as MSIE wouldn't do that it skipped over any issues by pretending it was HTML4?

That wouldn't be a standards compliance failure for FF/Chrome though. MSIE has often coped better with (forgive me) sloppy code, however.

Actually, the scenario was much simpler than that, to do with building dynamic HTML where form fields could contain characters like apostrophes.

It turns out that apos; is not a named entity in HTML4, but is rendered as the single character you might expect by both Firefox and Chrome. However, when we ran into IE not rendering it "properly", it turned out that we were wrong, and IE's behaviour was perfectly legal. (Whether it is standards-compliant to render a non-standard entity in this way, I don't know; the point was that it turned out not to be IE that wasn't compliant at all.)

I think I see now, you mean that as ' wasn't in the HTML4 spec despite the other browsers all rendering it consistently as an apostrophe MSIE not rendering it was not a breech of the standards.

So MSIE was compliant but just backward about it's approach to things that were beyond the standard. This presumably wouldn't ahve been an issue at all is MSIE supported XHTML ... but I digress, thanks for responding.

---

http://www.w3.org/TR/html4/sgml/entities.html

[backporting IE9.0 to Windows XP]: "It may be commercially sensible for them to do so, but that depends on many other factors beyond the preferences of the web development community."

It's not within Microsoft's strategy of planned obsolescence. For their continued survival they need people buying newer versions of the same software.

XP came out in 2001. According to Apple, Safari 5 requires OS X 10.5.8 (Leopard), released in 2007. Microsoft actually has a pretty good track record when it comes to supporting older versions of its operating systems. Just a bad record getting everyone to upgrade to newer versions.

Stop the presses. Apple software like iTunes and Safari STILL RUN ON WINDOWS XP. The difference is in how many users are on XP (50%?) vs. older than OS X Leopard (low single digits).

Related: Firefox, Chrome, Safari, and Chrome Frame are all more advanced than IE9 and all run on Windows XP.

>The difference is in how many users are on XP (50%?) vs. older than OS X Leopard (low single digits).

And the reason for that is probably that Microsoft keeps so much backwards compatibility that the cost of not upgrading the OS is much lower than on OSX.

> For their continued survival they need people buying newer versions of the same software.

Or they need people to be paying for commercial support of existing products. I'm not privy to any sensitive details, but I'm guessing they make the bulk of their real money from businesses, and that most large/profitable business customers have some sort of ongoing/bulk deal with Microsoft rather than paying for licences individually. Curiously, those large/profitable business customers are probably also the ones who don't like things like pushing updates every few weeks, because they (perfectly reasonably, IMHO) want a controlled software installation on their standard staff PC and they want to test any changes in-house before committing to adopting them.

That rings a bell. Commercial support of existing products. http://arstechnica.com/microsoft/news/2010/08/despite-petiti...