Anigozanthos

... 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.

There's been some discussion on the Opera forums about Opera and web compatibility, which has prompted me to blog this for future reference...

The navigation menus on the TPG web site are nearly unreadable in Opera, but fine in IE, Firefox, etc. More code Opera just can't handle?

Nope.

http://www.tpg.com.au/res/js/stm31a.js

These are old SoThink menus, long since updated by SoThink, but TPG persists in using them.

Line 1010:

nVER=parseFloat(a.substring(a.indexOf("Opera ")+6,a.length));

The menus are sniffing for "Opera " - note the space. That only appears in the User Agent string when Opera is identifying as Firefox or IE (which works around the problem). For Opera identifying as itself, the space isn't there, which results in the sniffing failing and the script determining that Opera is version 0! Which is too old for the script to handle.

The fix is trivial - delete the space:

nVER=parseFloat(a.substring(a.indexOf("Opera")+6,a.length));

I emailed the TPG web master many, many months ago (probably a year or two, now), giving them the exact file name, line number and change to make. Could they find the time to delete a single character? I guess not.

Not that Opera have released version 10 (yet!), but it looks like at least one site is going to reject Opera when they do. And where there's one site, no doubt there's hundreds of others Thankfully, a quick search doesn't quickly turn up anything similar, although there are plenty of other bad examples.

Anyway, here's the problem code:

if (navigator.userAgent.toLowerCase().indexOf("opera") != -1)
{
   isOpera = true;
   i = navigator.userAgent.indexOf("Opera") + 6;
   v = parseInt(navigator.userAgent.substring(i, i+1));
   if(v < 7)
      isOperaOld = true;
}

Need a clue? The substring will return exactly one character - the first digit of the version. Still need help? Version 10 will be identified as version 1.

If you're one of those people irritated at how poorly Opera appears to handle web site scripting - this is one of the bigger reasons. It's straight-out careless programming without thought.

I'll mention that the site in question isn't delivering bugs to just Opera. Their corresponding IE code had the exact same problem, except that IE is quite a bit further away from version 10 than Opera.

The problem remains for Opera:

1. Opera release version 10.
   
2. Web sites stop working in Opera, all other browsers work fine.
   
3. "Opera is a crappy browser, never works!"
   

Yet, where is the bug? What should Opera do about it? Never release a browser with a version where the first digit is between zero and six inclusive? Will the Opera after 9.5 be 70.0?

UPDATE: Bit late, but Hallvord has blogged on this too: 10 is the one.