From time to time the idea is put forth that Opera (and Firefox, for that matter) needs to start dealing with bad code. There are two problems with that view:

  1. Opera already deals with quite a bit of “bad code” (but there’s always room for improvement)
  2. Just dealing with bad code isn’t enough: you have to deal with it the same way someone else does.

#2 is the tough part.

The rules for dealing with good code are, for the most part, specific. If you encounter well-formed HTML, you can be reasonably sure you know what the author meant. But there are very few rules for dealing with bad code. Trying to "deal with it" means trying to guess what the author meant, and sometimes different assumptions are equally as likely.


<p><b>Here's some text</i> and here's some more.</p>

Did the author close the non-existent italics by mistake, meaning to close the bold? Or did he open bold by mistake, intending to open italics? Or is the closing italics tag left over from copy-and-paste? Depending on what assumptions the browser makes, it should display it as:

Here’s some text and here’s some more.

Here’s some text and here’s some more.

Here’s some text and here’s some more.

And that’s just a simple example. It gets wilder when you throw in issues like inline vs. block elements. A paragraph should never appear inside a tag for text formatting, like bold or italic. By all rights, starting a new paragraph (or more precisely, ending the previous one) should also revert to plain formatting. But a lot of old pages expect the formatting to continue into the next paragraph, because way back when, a P tag was a double-line break, not a container.

Now, suppose that Browser A always makes the first assumption, and Browser B always makes the second. If someone tests their code in Browser A, and it happens to be what they want it to do, they won’t necessarily notice that their code is broken. The result: the site looks wrong in Browser B, and the page author — who thinks the page is fine, since he tested it in Browser A — blames Browser B.

Multiply that scenario by millions of pages and you have a large chunk of the web as we know it today.

So the solution isn’t just to “handle bad code.” It’s to handle that bad code in the same way that the dominant browser handles it. And since there’s no document you can look to for guidance, that means taking every possible chunk of bad code, running it through the other browser, and seeing what it does to it.

And there are a lot of ways to break code!

Even Microsoft did this back when IE was new. At the time, lots of people were writing broken code and testing it by seeing whether it looked right in Netscape. So IE had to make the same assumptions Netscape did on certain things. Once IE became established, they diverged.

Some relevant articles:

This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.

Microsoft is really pushing for people to make sure their websites and apps are compatible with IE7. Apparently this is a real concern for a lot of people who relied on certain proprietary features, bugs, and quirks in IE6. I guess they figured they wouldn’t have to worry about future versions. (Hmm… I wonder where they got that idea?)

The fact of the matter is, I’m not worried. I tested my personal sites and the sites I’d built for work months ago, using the IE7 betas, and more recently with RC1. I made a couple of minor changes to some stylesheets, but that was about it.

Why? I’ve been writing standards-based code for years. I validate it from time to time, and I test to make sure it works in the latest versions of Firefox, Opera and Safari as well as IE. So the code was already portable.

Plus, anything new I’ve built since January has been designed with IE7 in mind from the beginning.

Most of the changes were to workarounds for IE6. Either stopping them from running on IE7 (if the bug was fixed), or keeping them running on IE7 (if it was done using a CSS hack).

The Web Standards Project has announced a joint task force with Microsoft to promote web standards in products like Visual Studio and ASP.NET.

I imagine this was probably a factor in the decision to divest themselves of Browse Happy last month. Certainly this project is more in line with their core mission—promoting the use of standards on the web—and fits right in with the Dreamweaver Task Force they ran with Macromedia back in 2001.

(via WaSP Buzz)

The Acid2 Browser Test is out, and any fears that it’s focused only on IE have proven unfounded. As Dave Hyatt remarks in his efforts to get it to work in Safari, “Every browser fails it spectacularly.”

The Acid2 test is a single page of HTML and CSS designed to use parts of the spec that today’s browsers handle incorrectly or not at all. According to the rules, the code should display a happy face… but at the moment it produced varying levels of gibberish. So far Firefox seems to handle it the least badly (I hesitate to say “best”), with Opera and Konqueror at about the same level (you can at least see a circular outline), and Internet Explorer looking like a piece of modern art.

Well, we know Safari is working on it (and the fixes should feed back into Konqueror). One of the test’s architects is high up at Opera, so you can bet they will be improving. I imagine people are already submitting bug reports to Mozilla. [Update: found the tracking bug in Bugzilla.] That leaves Internet Explorer. They’ve been notoriously reluctant to update their rendering engine, but they did ask for specific requests. I don’t have much confidence in seeing fixes in IE 7, but you never know…

Anyone want to place bets on who progresses the fastest?