function crashIE6() {
    for(x in document.open);
  }

Also, because getting awesome work done with jQuery is far easier for the seasoned professional than messing around with plain Javascript DOM traversal.

Of course, you still have to use native JS functions for a lot of stuff, so you're not taking a shortcut around JS. You're just skipping the parts that are time-consuming, awkward, and inconsistent across browsers, and getting right to the useful stuff: shorter, more powerful, more expressive code.

Or is that just 'for beginners'?

  for(x in open);

But if you mean "learn JavaScript" in the pre-jQuery sense, then what you really mean is "accumulate encyclopedic knowledge of all sorts of browser dependent bullshit that constantly thwarts every attempt to write clean, reusable code that actually works." In that case, jQuery (and other similar libs, of course) really does change the game. You can get pretty damn far without ever knowing a thing about the various incompatibilities; this, IMO, is one of the best things about the new sets of Javascript tools out there, they really are starting to bring us towards the point where you can just write clean code that does what it's supposed to, without working around bugs (features?) in other people's code.

That point is overplayed to the point of insanity. Unless you're targeting IE5, browser differences in js are minimal. Most of the inconsistencies are in layout.

As for basic CSS, yes, if you know the major pitfalls then IE6 isn't so terrible (when it was released a decade ago it was a breath of fresh air actually), but even that requires a constant vigilance against dozens of bugs that are a minefield for anyone who is not anticipating them due to years in the trenches. Oh you might be lucky and avoid them, or you might stumble upon them and rue the day you ever posted such a dismissal to HN.

Javascript has a number of similar pitfalls that are hard to be aware of and are fairly arbitrary limitations to place on your development. Frameworks paper over some of this stuff, but some of them are hard limits.

In my case for instance I am the lead dev on a VOD site showing feature-length films. You could watch one film on IE6, but if you watched 2 without restarting it would usually crash. We weren't using some bloated JWFlv player, we had a minimal, custom flash player designed to squeeze out maximum performance. There's absolutely nothing we could do about that, and just the support costs of reading emails from people whose browser crashed when they were watching movies was not worth it.

If a static site, yes, it isn't too hard. But a web app is another matter all together -- not only working around the issues but stopping you use features that better browsers offer.

- Security issue (this is internal to the installation site of IE6, and doesn't affect development all that much) - Performance issue (if you're doing something complicated in JS, it won't work in IE6. It will just be way too slow)

Just link the following URL as an image somewhere on a page (works on third-party sites that pass image URLs directly to browsers):

http://grack.com/crash.py

There's a crash in IE's URL parser that takes down the browser if it attempts to process this URL: "ms-its:%F0:". The above script returns an image to every browser, but a Location: redirect to IE6. If a site doesn't proxy images for its users, it'll send them to the link and take down the browser. Known by Microsoft, doesn't require scripting, still unpatched.

Source, for anyone interested:

  #!/usr/bin/python
  # http://grack.com
  import os
  import sys

  if os.environ["HTTP_USER_AGENT"].find("MSIE 6.0") != -1:
        print "Content-Type: image/png"
        print "Location: ms-its:%F0:"
        print ""
  else:
        print "Content-Type: image/png"
        print ""
        print open("crash.png").read()

Now all you need to do is create an argument to the url so that it takes dimentions in case profiles have a dimention limitation. This way we can crash IE on many sites all over the internets.

In IE6, <img src=FOO> is a superset of <script src=FOO>. Really.

Just don't style for IE6 anymore, there is no reason to make sure your website won't work on IE6!

If such a browser existed and explicitly mentioned the above restrictions/features, it would be trivial for most IT departments to put the browsers's .Exe in a read-only network share and put an icon for it on every user's desktop. The problem is that other than IE, every other browser is a pain to setup on a Windows network. I have Chrome installed on a couple of Terminal Servers and it took almost two full days to make it put the cache files in the right places. And I had to write my own script to empty the cache because there is no easy way to automate it. On the other hand, it is very easy to deploy IE7/8 but since many intranet sites have been custom written for IE6, it is not possible to upgrade to other versions of IE. Things break and it's very costly to fix them. I've seen a $400k software system that only works in IE6. The pages don't even load in IE7+ or other browsers. The upgrade to a version that is IE7-compatible is $300k. So for the IT department, it's either IE6 or $300k. Management does not care and should not care about IE6 working for all sites. They need IE6 to work on this expensive piece of software that runs their business.

Despite what people here on HN say, IT departments don't mind users using alternate browsers. Their problem is that Firefox, Chrome, Opera, and Safari aren't easy or even possible to setup in a server environment like IE is. Depending on which user belongs to which department and logs in from which location, I can configure their IE to automatically set homepage, proxy settings, privacy/cookie settings, and lots more. Forget features like these, with other browsers, I don't even get to set the location of the config files and cache folders. When you have 100 people logging on to a terminal server, you need to be able to configure these things or the entire server goes down because some user downloaded a partial 2GB file which is still in their cached folder and now the server is trying to save it back to their user-profile folder.

TL;DR version: Give me a browser that I can setup easily in corporate environment and I will set it up.

Not sure if this still works, but here's an old thread from when it seemed to work: http://forums.mozillazine.org/viewtopic.php?f=38&t=27113...

That said, I agree that in this day and age, it is inexcusable.

One other point, you may be unaware (as I was until pointed out to me) that 'gypped' is a racial slur against Romani (or broader, Italians).

When almost nothing will work on IE6, I hope that would encourage the "standard" to be updated. If all sites "sorta work" in IE6, there's no pressing motivation to upgrade.

While crashing people's browsers isn't exactly mature, dropping support for IE6 to the point of sites/apps not working in it is the right move (as Google has recently decided).

I also have to use IE6 at work. The problem is that the folks in charge say "Our entire intranet works in IE6. It may (or may not) work entirely in other things." So by their standard "everything" already works.

This assumes a policy of not needing to access anything on the wider Internet, and if there's a such a policy, it's for those in charge to determine or change.

Here's how we handle IE6 support: We have several large apps that are used by a lot of corporate/government offices. They have to fully work in IE6, no questions asked, that's just non-negotiable. At each new phase of development, we thoroughly test in IE6 before moving on to make sure things work. After doing this enough, you start to learn what will work and what won't and IE6 support becomes easier over time, and since the codebase is built with IE6 in mind from the beginning, it's not so bad, most of the time.

We have another large app that's not as restricted in where and how it has to work. It has a public-facing side and an admin interface. The public-facing side works fully in IE6 in terms of function. There may be a few pixels difference here and there in visuals, but as long as it still looks good and functions properly, we don't stress it if it's not pixel-perfect. The admin side is meant for users who are more tech savvy and the percentage of IE6 users is very low. What we do in that instance, and this is pretty much our standard aproach when IE6 support isn't essential, is make all of the core functionality of the app work with IE6 and then disable the bells and whistles that give the app additional functionality that adds convenience. We then let the user know that upgrading their browser will give them access to this additional functionality and make their user experience better. Hopefully, they choose to upgrade, but if they don't or can't, they can still do everything the app is designed to do. It just won't be as pleasant/intuitive/seamless of an experience.

As much as I hate IE6, I hate the idea of giving its users the finger and not allowing them to browse/use my app/site as best as their antiquated browser will allow them to even more.

If you bash IE6 hard enough, those legacy systems will HAVE to be upgraded because they'll be so monstrously expensive. It's a free market, if you want to affect change then manipulate the price of stuff.

I'm in favor of everybody using this plugin because it saves _me_ money (and time) as a developer if legacy systems have to be upgraded. I don't care if other people have to pay, you and I both benefit!

http://portableapps.com/apps/internet/firefox_portable

http://portableapps.com/apps/internet/google_chrome_portable

Obviously the usual caveats apply to software from 3rd party sources, but portableapps.com has been going for years with no complaints.

PS. I'm all for newer, better browsers; I myself use FireFox. But content should at least be usable on every browser, that's more important than that the site looks pixel-perfect in those older browsers.

Newer web apps rely heavily on javascript and css, and it might take you 20% longer to make your site work for 5% of users. Its just not worth supporting in my opinion as the time you spend on IE6, could be spent making much cooler things for the newer browsers.

Exactly. IE6 is a pain, but the extra work is worth it to me so as not to send away potential customers. Perhaps when IE6 gets below 5% marketshare we'll revisit the issue.

BTW - if any of you guys are getting hung up on a particularly nasty IE6 bug, feel free to drop me a line (within reason). I'm adept at fixing them.

I hate IE6 as much as the next guy, but most people running it don't have the choice. If you choose to be hostile to helpless users subject to poor management, they're going to blame you and your site, not their browser.

>> but most people running it don't have the choice

how do you know this ?

What if you want to iterate over the return value of document.open? It's perfectly legal ECMAScript.

If I write a program that randomly crashes when I type in the URL of your website, should you be liable for that? Of course not. Any crash is Microsoft's fault, not the web developer's.

1) Intent matters. Clients won't go to your site.

2) It is MS' fault. No amount of JS should ever crash the browser, at worst it should replace the page with "sorry this page has crashed, please continue browsing elsewhere" like what chrome does.

As a technology lead and entrepreneur, this is a disaster, and I'd have to ask serious questions if anyone on my team were to go anywhere near it.

As a developer, LOL.

Ok found the link:

https://bugzilla.mozilla.org/show_bug.cgi?id=520086

Strangely this does not crash google chrome. Impressive!!!!

Err, correction, the regex now runs reasonably fast in the most recent of regex engines but I think on a long enough string it should still fail.

The string "dead:parrot(skit = 123372398547895743957574395743957439579435" now kills the browser.

However, unlike firefox in which regex runs in C space not JS space, google chrome/chromium recognizes that the page is unresponsive completely and kills the process, only the one process is unresponsive the rest of the browser works. Good job google!

Edit: This will kill Opera, Firefox (any), IE (any)

http://raven-seo-tools.com/blog/2675/crash-ie6-with-only-css

Edit: I'm surprised to be down-voted. Many clients that have standardized on IE6 still exists. 3 years ago there were even more clients that used IE6, and probably forbid other browsers, including IE7/IE8.

I've personally fought for making my web apps work on every reasonable browser, and gotten the arguments that the client will not pay for anything but excellent IE6 support.

Tell the visitor to install google chromeframe and give them a download link:

http://dl.google.com/update2/installers/ChromeFrameSetup.exe