IE vs. Standards

Joel once again has an interesting article about Marian Headphones. To sum up, IE8 defaults to standards compliant which breaks most of the existing web sites that worked around earlier version’s of IE’s poor standards compliance. Idealists believe that is great! Pragmatists believe that breaking most of the web is a bad idea.

Here is Joel’s prediction:

The IE8 team going to tell everyone that IE8 will use web standards by default, and run a nice long beta during which they beg people to test their pages with IE8 and get them to work. And when they get closer to shipping, and only 32% of the web pages in the world render properly, they’ll say, “look guys, we’re really sorry, we really wanted IE8 standards mode to be the default, but we can’t ship a browser that doesn’t work,” and they’ll revert to the pragmatic decision. Or maybe they won’t, because the pragmatists at Microsoft have been out of power for a long time. In which case, IE is going to lose a lot of market share, which would please the idealists to no end, and probably won’t decrease Dean Hachamovitch’s big year-end bonus by one cent.

What camp are you in? Pragmatist or Idealist?

I don’t think it is completely cut and dry. I am a practical idealist personally - when possible we should do what we can to move toward the ideal standards, but continue to make existing stuff work as much as possible. Maybe with a warning that something is non-standards compliant. I am a big fan of flagging things deprecated when developing libraries. Leave the old methods in place, but let the users know that they will be going away. If possible provide tools and tips to aid in migration.

The point Joel makes that a lot of pages can’t be updated for various reasons is a valid one. Same is true of deprecating and eventually removing methods in a development library. Developers may skip a few updates, or might not have access to all the source code to make the changes required. This is especially a big deal for run time libraries that existing compiled code depends on.

Delphi has typically been really good about marking things as Deprecated and giving users plenty of warning that things might change. Indy on the other hand is pretty bad about breaking things between releases, and not providing a very clear path to making your code work with the new version. Microsoft is usually really good at supporting their users (Office) but not so hot with their developers and leaving code written in earlier IDE’s unable to compile in the new version.

I agree that is good for IE to continue to become more standards compliant, and they are in a mess of their own making, but I do believe that Joel’s point is that a lot of the standards were incomplete or didn’t cover things that were needed. Like the now deprecated <blink> tag was not in the standard, and it was only the fact that Netscape supported it as a result of user demand that caused it to be added. Netscape, Mozilla and Opera still support it, although Internet Explorer has dropped support for it.

I don’t think it is in IE’s best interest to release a browser that appears to all those browser detection scripts as IE and causes the page to render funky for IE when it is no longer necessary. This results in messed up pages. Maybe they need to change the IE user agent based on what mode IE is running in so that if it is running in standards mode then pages don’t assume it is non-standard. . . . Opera does that, which is pretty effective.

Tags: , , , , , ,

2 Responses to “IE vs. Standards”

  1. Xepol Says:

    Short term pain for long term gain. About time someone embraced the concept.

    Doesn’t matter what MS does anymore, the same people bitch. They don’t even care if they make sense anymore. IE doesn’t adhear to standards and breaks everything, IE adhears to standards and breaks everything.

    It isn’t about the pragmatists vs the idealist, it is all about bashing MS. Enough is bloody enough.

  2. d.cornelius Says:

    I’m a “best practices” person, so I’ll always vote for the idealistic method. Yeah, it’s gonna hurt; yeah, there will be pages that won’t work any more; yeah, there’s going to be lots of effort to fix everything. Too bad, it should’ve been done right in the first place. Or maybe it’s not that it wasn’t done right in the first place, but that there’s just a newer, better way to do it and we should throw away the old code. It’s helpful to review everything once in a while anyway.

    The content management system I chose to build my web site in, Drupal, is based on this concept. I recently had to do a major overhaul of my site and a client’s site just to get them to up-to-date with the latest version of Drupal so that the site would be ready for PHP 5. I’d rather have to do that work and know I’m keeping up with technology, than to have to bring along baggage of old routines.

    There was an unexepected benefit of updating the web sites. I learned about some new modules that were available and changed the data structures to accomodate them which will actually give me more flexibility. If I hadn’t needed to update the sites, I wouldn’t have discovered these new features.

    And I have dealt with changed Indy functions in a Delphi program. I work for a boss that only cares if it is working–we gotta move on to the next project (”if the old version worked, and we have a program similar to this new project, copy it and make it work.”). Every fiber of me goes against that concept. However, it’s also why I’m not in business for myself anymore. I spent too much time “doing it right” rather than “getting it done.”

Leave a Reply