Adam Wolfe Gordon <awg@xvx.ca>
Hosted at Linode
Design by Minimalistic Design
Powered By Loathsxome

26 March 2008

Joel On Jon Postel

Joel on Software has an interesting article up called Martian Headsets. Joel describes, very nicely, the issues facing Microsoft (and all browser-makers) as they come out with new versions. In many, many ways I agree with what he says, however I take issue with one part:

And this is where Jon Postel caused a problem, back in 1981, when he coined the robustness principle: "Be conservative in what you do, be liberal in what you accept from others." What he was trying to say was that the best way to make the protocols work robustly would be if everyone was very, very careful to conform to the specification, but they should be also be extremely forgiving when talking to partners that don't conform exactly to the specification, as long as you can kind of figure out what they meant.

My issue with this bit of the article is that this is really a mis-application of Postel's robustness principle. After all, it was intended to apply to protocols. HTML is not a protocol, it's a language. It says so right in the name. Browsers do speak a protocol (HTTP), and in this part of their interaction with the internet, they definitely should follow the robustness principle, but to apply to robustness principle to a language is nonsensical.

Which isn't to say that a misinterpretation of the robustness principle wasn't one of the factors in the current browser-HTML-standards mess. No doubt, someone somewhere said "we should be lenient with our HTML, so that we'll work with as many pages as possible," possibly thinking (s)he was applying the robustness principle, possibly thinking (s)he was just being a nioe person. However, this is not a correct application of the robustness principle at all.

To see why this is a misinterpretation, let us consider how one might apply the robustness principle to another language: C. Your C compiler would want to be strict with its output; it would always produce valid machine code. Good, wouldn't want it to produce an executable that doesn't run. But your C compiler would also be lenient with input. That is, if I declared a function int func(arg1 int, arg2 char *), it would assume that what I really wanted was two arguments of types int and char *, called arg1 and arg2, and generate output accordingly. Of course, down this path lies madness. What if arg1 and arg2 really were types? No reason they couldn't be. Then what is the interpretation of that line? It's nonsense. Making assumptions about what the user intended in C would just be a bad idea. Why is HTML any different?

In the end Joel and I really see things the same way: there should never have been a quirks mode, every browser should have forced people to write valid HTML and people should have listened. But while Joel feels that Jon Postel's robustness principle is to blame, I assert that any application of Postel's robustness principle to a language is a misapplication. Either way, it is absolutely a hard problem that the browser developers of the future will have to face, and I don't see an easy way out. If they keep quirks mode, they perpetuate the problem of poorly-written webpages and crazy browser-specific hacks. If they make standards mode the default (or only) choice, they end up with users complaining about broken web pages and reverting to the previous version. No easy choice there.

link -- []