Are you getting used to IE8's progressive enhancement problems?

There's some new discussion

[Clark]

Zeldman and some other guy have some more debate on IE8 if you didn't catch it. I'm finally respecting that IE team has struggled long and hard for a solution to being standards compliant without breaking the intranets and web clients and accepting that one line in the header isn't that big a deal.

Also, it sounds like once HTML5 is implemented widely, this won't matter.

But did I understand correctly that you'll have to target a specific version? IOW, you can't say "IElatest", you have to say IE8, or IE9, or IE10?

If so, then you have to go through all old code for each new IE and rewrite that line each time?

[vincevincevince]

Clark, you seem very upbeat about it. I can't say I share your optimism or respect for a team with a long history of failing to deliver. With a readily available test suite and clear specifications, I can't see any excuse for the biggest software manufacturer in the world not to have delivered 100% standard compatible browsers every single release.

IE7 was a great disappointment to me; with such a delay before the release I was hoping for them to finally provide a standards based browser with no Quirks mode or other legacy support. So, some proportion of the websites who now rely upon non-standard code to work with IE would look a bit wrong for a while. If they got any traffic worth mentioning then their owners would update them to be standards compliant. The world would continue to turn.

[SuzyUK]

But did I understand correctly that you'll have to target a specific version? IOW, you can't say "IElatest", you have to say IE8, or IE9, or IE10?

..there is an "IElatest" = [ie=edge], developers are however, for the time being, being discouraged from using that and I think I can understand why.. OK perhaps for your bleeding edge hobby site where you can pop in and change things on a whim should an IE release have a bug, like we did for NN, FF, Opera in the early days of their steps to compliance.

But developing multiple client sites, it would not be wise yet, just like those same early hacks for already compliant browsers didn't proliferate IE hacks should not be allowed to either. IE8 will be a massive change for IE, their whole way of rendering must be going to change if hasLayout is to be removed (as has been announced previously) so it would be very unwise to expect that IE's new render engine will get it right first time, Nobody elses did

If so, then you have to go through all old code for each new IE and rewrite that line each time?

Yes, that's the idea but you only need to update if you want to - this is the beauty for those with client sites, if the site works now, in IE7, why would you want to update the tag, the site will still work in IE8, IE9 etc.. the outside world will know no difference, more importantly the client is happy that a new "forced update" didn't break anything.

The developers in us may want to test sites in IE8 (or whatever version we're at) when developing a new client site in order to develop to the latest standards or on a personal test suite site in order to keep up to date with IE's "real" compliancy status. We will be able to that simply by changing the tag manually, if something's "broke" we can recode or roll back to the last stable version. best of both worlds perhaps?

I hope these baby steps shouldn't be needed for too long, and that developers will eventually be able to trust IE updates and use "edge", indeed the fact that HTML5 doctype triggers "edge" seems to be a good indication that IE eventually do hope to roll out new versions that won't "break" sites.

[Clark]

Thanks Suzy.
Vince, I'm far from upbeat about internet explorer. But I'm trying to put myself in the shoes of the developers. They are standards aware. You can be mad at Microsoft, but they hired the right guys for the job finally. Those guys are concerned about your needs. But they have a requirement that you don't care about. Not to break their clients. They are willing to solve this by adding a rendering version for each IE from 6-8 right now and so on. That's a huge burden on them at no cost to us. If they are willing to do that, they must consider this problem enormous and willing to work harder than the developer to solve it.

I personally don't use IE much at all. And as time goes on will use it less. Right now I only use it for the couple of sites that don't work as well in FF for some reason I never bothered to figure out.

I wish IE didn't exist frankly. But I am upbeat that they are upgrading the browser to standards. And realizing that the price is just one line of code. I can live with that.

Is it the best solution? I have no idea. But I'm not going to go crazy figuring it out or getting mad at them anymore. I'm going to add that line of code and just be happy that soon most of the web will be on some kind of client that will use web standards.

Hopefully the installed base of IE6 will soon be low enough to be ignored...

[Achernar]

Yes, that's the idea but you only need to update if you want to - this is the beauty for those with client sites, if the site works now, in IE7, why would you want to update the tag, the site will still work in IE8, IE9 etc.. the outside world will know no difference, more importantly the client is happy that a new "forced update" didn't break anything.

IE8 is supposed to be standard compliant.
If you have coded your pages correctly: conditionnal comments targeting the correct IE version to load special CSS, but not for IE>7 ; why on earth would you like to prevent IE8 rendering in "real" standard mode by default?
Unless you know IE8 will be almost as crapy as previous versions. And IE9... until v666, the very first standard compliant version of IE. :)

[edited by: Achernar at 3:37 pm (utc) on Feb. 20, 2008]