61 Version information leads to browser monopoly

I previously explained how version switches in browsers reinforce browser monopolies, and thus slow progress on the Web.

posted at 06:15 pm on January 22, 2008 by David Baron

62 Untitled

If that browser has a single bug that affects a critical part of the application, the team has to scramble to fix the break as soon as they hear about it from a user (or several hundred). With version targeting, the team can test the new browser version internally before updating the meta element (or the HTTP header) to add support for that new browser.

Uh, you realise you just shifted the responsibility for a dealing with a browser bug onto the users of the browser.

My guarantee that my page displays correctly is (should be) the standard. If you can’t stick to it well enough to provide a reasonable rendering of my page then you shouldn’t be in the browser market.

If I decided to break standards compliance and use non-standard markup and styles on my page, you can bet I’d get no sympathy from people when I told them it didn’t render properly. Why should the browser makers get it any easier?

It’s only been possible to take this attitude recently, since there have been browser vendors who can create reasonable renderings of standards-compliant pages, and it’s an attitude that you can now start pointing at people creating new, badly built pages.

Microsoft has to bear the burden for not meeting standards properly in the past, and letting the situation get as bad as it is. It’s not unforgivable; someone mentioned earlier that the web is still in its infancy and there were bound to be things that went wrong. However, the solution to having broken the web is not to fix it by fouling and clogging it up for the future.

posted at 06:30 pm on January 22, 2008 by Gareth Adams

63 Better for us!

First question – how many websites that were designed to web standards broke under IE7? Or Firefox 2? The only sites that have broken (as far as I know) are those that were hacked together out of play-dough and sticky-tape and written in green crayon. So now that IE7 and Firefox 2 are here, anyone whose site is broken by web standards and relies on IE6 hacks is probably stuffed up like a turkey already. IE8, IE9, Firefox 10 and Opera 27 won’t make it any worse…

Second question – the more old hacky websites are broken by new browsers, the better it is for us! Anyone who can design a website that works is going to be in higher demand to redesign and replace the old-skool kludgey websites that are broken. That’s good!

posted at 06:37 pm on January 22, 2008 by Stephen Down

64 Untitled

Now sure, you could just shrug it off and say that since IE6’s inaccuracies were well-documented, these developers should have known better, but you would be ignoring the fact that many developers never explicitly opted into “standards mode,� or even knew that such a mode existed.

A developer should not need to “opt in” to standards mode, it should be the default behavior.

Microsoft reached out to The Web Standards Project (of which I am a member) and to several other standards-aware developers, and asked for our help in coming up with a better method of allowing developers to “opt in� to proper standards support.

Again, this seems like a very foolish approach. Essentially, this is encouraging developers to NOT develop to standards. Developers should have the option of “opting in” to non-standards support, not the other way around.

posted at 06:42 pm on January 22, 2008 by Peter Foti

65 Once Again Microsoft Infuriates Me

New versions of Safari, Firefox and Opera have all come out and I’ve NEVER had to create workarounds because those browsers were worse than the previous versions. Each newer version fixed bugs in the previous. Yes, new bugs may be introduced, but those bugs should be fixed with patches, not left in until the next version.

I also read on the IE Blog that they thought developers expected IE7 to act like IE6. I expected the opposite. I coded pages to work in standards browsers, then hacked for IE6. I expected IE7 to act like Firefox, Opera, Safari, et. all. I was disappointed then, but hopeful for IE8. Now I’m disappointed AGAIN with IE8. Here’s how to resolve the problem:

1. No doctype or malformed doctypes should trigger Quirks mode.

2. Including a proper doctype should trigger full Standards mode, without regard to which standards the browsers support. It just means the browser supports standards and I’m coding to standards.

3. Get rid of conditional comments in standards mode. If the browser properly supports Web standards, there is no need for conditional comments.

I don’t code to a certain rendering engine, and certainly not to a certain version of that rendering engine. I code to the standards. The standards themselves have backwards compatibility and forward compatibility in mind and that’s what we need. I don’t want to change every site I’ve made in the last X number of years because Microsoft came out with another broken browser. I guarantee Internet Explorer will be the only browser we need to use this new META tag with. When only one browser requires this, that right there is a red flag saying something is still broken and needs to be fixed.

posted at 06:44 pm on January 22, 2008 by Greg Burghardt

66 'Opt-out' surely, not 'opt-in'

Essentially, this is encouraging developers to NOT develop to standards.

Looks like someone’s beaten me to making my point, but surely the whole thing should be a case of opting-out of the all singing, all dancing brand spanking new standards-based rendering engine?

Developers should have the option of “opting in” to non-standards support, not the other way around.

I can see why, as a company, Microsoft would make this decision though – many of Microsoft’s apps use the IE rendering engine to render user interfaces and with the introduction of Internet Explorer 8, many of these interfaces could be adversely affected. I’ll bet that there are product managers all over Microsoft lobbying for this meta tag so that their interfaces don’t break once IE8 is installed.

I’m not saying I agree with Microsoft’s decision to force those of us who care about standards (count me in) to add this meta tag to their pages, but I can see why they would choose to do it.

With that in mind, I see the ‘edge’ declaration as a solution to a problem that should never have existed in the first place.

posted at 06:55 pm on January 22, 2008 by Anthony Williams

67 Am I the only one who likes this idea?

From what I can see, this is actually a good idea. If you’re a browser vendor, and you don’t want to support this… well, don’t. No one’s forcing you to. Microsoft is just giving developers a way to say, “This page works with IE7. If you can, make it work like IE7 did.”

Saying “everyone should just follow the standards” is good and nice — except that the standards are very complex, sometimes ambiguous, and occasionally internally inconsistent. Just like C++ code, standards are written by people and can have bugs.

Also… IE isn’t the only browser that changes behavior across versions. Firefox 3 passes acid2 whereas FF2 doesn’t — obviously, the two versions mean something slightly different when they say they’re standards-compliant. Even in the “equal” world of standards-compliant browsers, some browsers are more equal than others.

As someone who builds intranet-style web applications (that work cross-browser, thank you very much ;-) I’d love to be able to pin my app down and say “This works with IE7 and Firefox 2 and Safari 3. Browsers, if you can act like any of those, you’ll deliver a good experience to my users.”

And I know it’s a good idea to test your web work with every browser you’ll want to support. Are you sure you’ll be in your current job, ready to do that, forever? Are you sure you’ll be able to spare the time to do that testing before users get new browsers?

posted at 07:01 pm on January 22, 2008 by Nate Vack

68 @Nate

It doesn’t do what you are thinking it does. You need to add this magic tag to make IE8 act better than ie6/7.

This isn’t going to fix the testing with every browser problem. It just makes testing harder, because you’ll have to test each browser and test each browser at different versions.

So, you’ll be testing:

• IE8 running as IE8, IE7, IE6
• IE7
• FF2
• FF3 running as FF3, FF2, FF1.5
• Opera9 running as opera9, opera8
• Safari3 running as safari3, safari2,

• safari2

Why do you have to check this? To see if your page works better as a newer browser version or an older one.

What a mess.

This is a horrible idea. I don’t mind adding an opt-out like “I really need IE6 type behavior”, but adding opt-in for the best standards compatibility is ridiculous.

Ciao!

posted at 07:15 pm on January 22, 2008 by Christian Holtje

69 Untitled

“Saying “everyone should just follow the standardsâ€? is good and nice—except that the standards are very complex, sometimes ambiguous, and occasionally internally inconsistent.”

You mean like IE is? At least all other browsers do a significantly better job at it then IE.

“IE isn’t the only browser that changes behavior across versions. Firefox 3 passes acid2 whereas FF2 doesn’t”

Other browsers do not change behavior. Passing Acid2 is done by adding features and fixing bugs, not changing how the browser acts in different contexts.

posted at 07:17 pm on January 22, 2008 by howard fine

70 Scramble to fix for new version?

Aaron, in comment #43 you say: “Let’s say that a new browser version launches 3 months after the application is brought online and the team has coded to web standards, has used unobtrusive JavaScript, and everything else that is considered a best practice right now. If that browser has a single bug that affects a critical part of the application, the team has to scramble to fix the break as soon as they hear about it from a user (or several hundred).”

this is the line i heard often from many of our suppliers for large enterprise systems (SAP etc) with web interfaces. they were frantically telling our university staff not to upgrade to IE7, because their systems broke, a month or so before launch of 7. strangely though, fairly feature-complete beta versions of 7 were already available to everybody ages before then…the developers just didn’t bother testing their product (written in superbly poor, IE6 specific code, which wouldn’t even run in Safari or Firefox) against it by the look of it. i seem to remember even 37signals moaning when IE7 was released. so, i don’t quite buy the “totally surprised by the unexpected new release and the bugs/differences in rendering that we scrambled to fix it” line.

“With version targeting, the team can test the new browser version internally before updating the meta element (or the HTTP header) to add support for that new browser.”

or they can leave it exactly as it is and think that current and future browsers will faithfully emulate the old browser behaviour.

posted at 07:17 pm on January 22, 2008 by patrick lauke

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)