Anigozanthos

The news that IE8 specially configures intranet pages to display in a compatibility mode is no surprise to me.

I blogged about Microsoft's compatibility problem several months ago, and decided that they needed two browsers - one for private intranets and one for the public Internet. All Microsoft have done here is roll all that into a single browser.

Håkon is wrong to complain about that. Microsoft have no choice unless they don't want any of their corporate customers to upgrade to IE8. How would that help improve web standards? No, the best way to improve web standards is to allow private sites backward compatibility, while allowing public sites to default to web standards. That will allow the maximum number of users to upgrade to the vastly more standards-compliant IE8, which in spite of how a lot of people feel, will eventually become the most widely-used browser.

Håkon is not wrong to complain about the broken page icon. Icons in status bars are usually there to draw your attention to them, indicating something important or a potential problem. From a users point of view, being in standards compliant mode is neither. All users care about is if the page looks and works OK. Web developers will ensure that will be true for their IE visitors. It is absolutely wrong to associate a broken page icon with standards compliant web pages and rendering modes.

What would be useful is an icon to indicate whenever the browser has had to guess how to handle broken page code - typically invalid HTML or CSS. Browsers should never have to guess. If they do, then web developers are relying on luck for correct display. Developers should want something more reliable than that, and their users certainly do!

That's really what everyone wants. That every web page should just work. No buttons, no icons, no special rendering modes (it's OK if the different modes are hidden, as they are now). Everyone agreeing to and using the same standard is the only way to get there.

... As It Applies To The Web

The Robustness Principle (AKA Postel's Law) was conceived during the writing of the TCP Internet communications protocol, back in 1981. It is often quoted as:

Be conservative in what you send, liberal in what you accept.

Sometimes it is quoted on the Opera user support forums by people frustrated with Opera's seeming inability to handle web sites as well as Internet Explorer or Firefox. The reasons behind all the web compatibility problems are many and varied, and beyond the scope of this post. The purpose of this post is to show that the application of the Robustness Principle is at least partly responsible for some of the so-called Opera compatility problems.

Application of the Principle

When it comes to web browsers, it's typically the second part of the Principle that's stressed, never the first. The truth is, for robust "it just works" functionality, both parts are equally important.

It is vitally important that when faced with some hiccup in the data, browsers do not fall over. Hence, "be liberal in what you accept". It is just as important when sending data, to make sure that it conforms to all the published rules. Any communication involves at least two parties, and in order to be successful, the language used must be the same. If you're not certain exactly how your language may be interpreted by the receiver, you should make sure what you say is as simple and correct as possible. Hence, "be conservative in what you send".

Browser developers have almost turned themselves inside-out doing the "be liberal in what you accept" part. Web developers have virtually ignored the "be conservative in what you send" part.

What does "being conservative" mean for a web developer? At the very least it means the code should conform to published standards, namely the HTML/XHTML, CSS and ECMAScript standards from the W3C and ECMA organisations respectively. That's the only way to ensure that everybody (browsers and developers) are speaking the same language.

Where the specifications are clear, web developers should follow the spec. Where the specifications are unclear, or where they say things like "the results are implementation dependent", then web developers must expect different browsers to do different things and code accordingly (the most robust thing to do would be to avoid unclear functionality completely).

Beyond that, it also means web developers should limit themselves to features widely supported by most browsers. As an example, for nearly a decade HTML 4.01 has specified that you can align table cell contents on a character - for instance, "." to align on decimal points. Very handy for tables of numbers, yet I don't know of a single browser that supports that. (In the defence of browsers, support for that feature is not required.)

If you were to sample sites on the web at random, and test them to see if they conformed to published standards, you'd find probably more than 99% would fail. In essence, that means that web developers have failed to meet their half of the Robustness Principle.

However, even simply following the published rules is not enough. The fundamental problem with the Robustness Principle is that the rules change. Things that were incorrect and therefore ignored according to the Principle, can become correct and require specific behavior as they are implemented. As browsers implement new functionality their behavior naturally changes from earlier browsers that ignored unimplemented features. This is where some "incompatibilities" emerge.

WebForms2

WebForms2 is an extensive addition to the HTML specification. It adds significant functionality to the form controls provided by web browsers, including date (calendar) pickers and field format validation, among many others.

This new functionality has naturally required new HTML parameters (attributes) to be defined in order to request the new functionality. The problem is that many web sites were already using the same parameters for their own use!

The thing is, before WebForms2, the use of such parameters was illegal if you followed the HTML standard. Technically speaking, web sites should not have been using such parameters at all, but following the guide of the Robustness Principle, browsers silently accepted the illegal code.

Then a year or so back, Opera became the first browser to implement WebForms2. Web sites broke, because the illegal attributes they had been using suddenly took on new meaning and different functionality under WebForms2.

For example, this is the reason Opera cannot download printer drivers from the Epson Australia web site. One of the pages in the download process uses a WebForms2 parameter in such a way as to break the Epson Australia server scripts, which results in a never-ending loop of download questions, and Opera never getting to the actual download.

addEventListener

This is how standards-compliant browsers such as Opera, Firefox and Safari allow events to be used on web pages. This function takes three parameters: the type of event to be listened for, the function listening for the event (handling it), and a flag indicating if it is a "capturing" listener or not. Don't worry about what "capturing" means. The truth is, I don't really know the specifics! The specifics aren't important, anyway.

What's important is that up until a few months ago not one browser supported the "capturing" mode - the only mode they supported was the "non-capturing" mode. Following the Robustness Principle, if a web developer happened to request the "capturing" mode, the browsers all helpfully ignored that request and selected the "non-capturing" mode instead.

The problem is that a few months ago, Opera became the first browser to support the "capturing" mode. Suddenly, a good number of web sites stopped working. This was because they were requesting "capturing" mode event listeners, but were coded to only work correctly in the "non-capturing" mode. Browsers had previously accepted the unsupported "capturing" mode without a murmur, giving web developers no indication anything was wrong.

display:inline-block

This is a bit of CSS that is well-supported by Opera and Safari, poorly supported by Internet Explorer, and not supported at all by Firefox. Nevertheless, I have seen several web sites use it, and always in such a way that Internet Explorer ignored it. The result is that Internet Explorer and Firefox effectively ignored the command (following the Robustness Principle), while Opera and Safari understood and processed it. The result is a corrupted web site display in Opera and Safari, but a perfect looking web site in Internet Explorer and Firefox.

"display:inline-block" isn't the only problem CSS. Threads on the Microsoft TechNet forum have huge extra spaces all over the place. This is because the site uses "white-space:pre-wrap", which is again only supported by Opera and Safari. The forthcoming Firefox 3 adds support for that CSS, so Firefox 3 has worse compatibility with that site compared with Firefox 2.

Being Robust is not Being Compatible

This post should by now have clearly demonstrated that simple acceptance of incorrect code will have significant consequences later on. The pain avoided today is simply deferred until tomorrow.

In many ways, the Robustness Principle is actually creating a web that is less robust! It certainly does nothing to fix compatibility problems - rather it creates them!

The solution to web site compatibility problems cannot be found in the Robustness Principle.

No Clear Solution

There is no easy solution to these sorts of problems. The only real solution is to get web developers to avoid unsupported features and to rigorously stick to published rules for HTML, CSS and JavaScript. However, the first browser to dump the Robustness Principle and refuse to accept broken code would quickly become an outcast and ignored by both web developers and users alike.

Education, while keeping the Robustness Principle is in my opinion one of the better solutions. The best example of this I've seen is the iCab smiley. If all browsers could implement a similar feature it would provide a subtle hint to web developers that all is not right with their code. They might be less likely to produce incorrect code if they knew that their visitors could easily see that their code was incorrect.

Such a feature would not fix all incompatibility problems, but it would be a big step in the right direction.

Everybody - web surfers, web developers, browser developers - we all want a web that "just works". Blind acceptance of incorrect code is not the answer. The solution must lie elsewhere.

Last post I talked about a website with broken version sniffing. It's now been a little over a week since then. I emailed them at the time, but have yet to receive a reply of any sort. The problem still exists, so I don't feel guilty at all about naming that web site now...

Congratulations to ... The Australian Bureau of Meterology!

... and their browser sniffer: http://mirror.bom.gov.au/products/IDR.browser_check.v07.js

The "good" news is that Opera is far from the only application to suffer from this sort of short-sightedness. I mentioned that IE has the same problem on the same site, and a comment to my previous post mentions Flash version sniffing with the same affliction.

Although the cynic in me suspects that sites will have different Flash version sniffing code for different browsers, and only the path followed by Opera will have the bug. I will be very happy to be wrong, though!

EDIT: It's now 19-December-2008, and I've just received notification from the BOM that they have fixed their code. Finally!

For the latest Opera snapshot, hidden document.all functionality has been implemented.

Even if this results in some web sites breaking, this is good news on the "web site compatibility" front, as now all non-IE browsers (Opera, Firefox and Safari) now handle document.all in more-or-less the same way. Web developers love consistency!

For a while I've been wondering why the "on strike" cricket bat on the FoxSport cricket results pages (example) has been misplaced in Opera, but OK in Firefox and IE. The HTML code is:

<strong class="on-strike" title="On strike">On strike</strong>

which looks simple enough. The cricket bat image is put in using CSS styles.

It turns out the problem is caused by the CSS styles, and the way the site works around IE bugs and a Firefox missing feature. The styles in question are at the end of http://www.foxsports.com.au/css/ashes/0,24345,,00.css :

.on-strike {
display:inline-block;
text-indent:-9000px;
width:21px;
height:22px;
position:absolute;
margin-top:-4px;
margin-left:2px;
background: transparent url("/images/bat.gif") 0 0 no-repeat;
}

* html .on-strike {
position:static;
display:inline;
}

The on-strike element is a <strong>, which by default is an inline element. The CSS standards say that text-indent and width/height do not apply to inline elements - they only apply to block elements. The text-indent is needed to shift the text off the screen and the width/height are needed for the cricket bat image to show correctly.

IE has buggy inline support, which allows the text-indent and width/height to be applied as the site requires.

Firefox and Opera follow the standards, so the site has ensured they don't get IEs inline styling via the "* html" hack. Firefox doesn't support display:inline-block, so the site works around that by specifying position:absolute, which forces the browser to treat the element as a block. Opera supports both display:inline-block and position:absolute and the combination of the two results in the misplaced cricket bat.

If display:inline-block is removed from the styles, Opera displays the page just like Firefox, i.e. correctly.

What I don't understand is why the site didn't ditch all the styling funny business and just have:

<img src="/images/bat.gif" width="21" height="22" alt="On strike" title="On strike" />