A pedant that hangs out in the dark corner-cases of the web.

Tuesday, September 13, 2005

Why errors are important, and code coddling is harmful

Web browsers have historically been lenient with HTML errors, making assumptions about the author's intent. This is bad, for at least three reasons.

First, once errors accumulate, the collection of assumptions tend to result in surprising behavior. Typically, once a tipping point is reached, something unexpected happens to an element that is connected only through an obscure chain of assumptions to the last change. Author productivity and sanity are both dramatically impacted when this happens.

Second, it creates a second, de facto standard. This "quirks mode" is rarely documented very well, and typically is implemented in the way that is easiest for each vendor. This results in an arbitrary, capricious, proprietary specification that must be reverse-engineered and maintained by all vendors. These multiple engines add significant overhead and constant development to browser software in order to match other vendor changes. The result, from the user's perspective, is a bigger, slower program with frequent compatibility problems.

Third, it's presumptuous. Imagine if JavaScript/JScript/ECMAScript or a general-purpose programming language like C/C++/C# were handled this way. Syntax errors would not be reported, and a best guess would be made about the author's intent. Does anyone believe this would be anything other than a complete disaster? (OK, Perl does a little bit of this, but it's part of the language design, so is documented, and tends not to overreach.)

The Internet has become a collection of pages cobbled together out of a mix of invalid markup, presentational HTML, and CSS styles with significant workarounds. As developers, and as developers of authoring tools, we need to start sanding the bottom of the drawers, so to speak. It's time we start taking a little more pride in what we produce, and not just because it makes our jobs so much easier. Of course, we also need to continue leaning pretty heavily on certain vendors.

Open Source: How problems stay solved

Here's the thing about proprietary code: once a problem is solved, only the company that developed the solution can use it. Everyone else must constantly waste effort re-implementing a solution to the same problem.

This is actually good for a while, because it can lead to better and better solutions for an issue. Too often, though, long after the best solution is found, the current intellectual property climate means ownership of that code forces others to use a different, less optimal approach. This slows innovation.

With open source, once the community determines the best possible way to address an issue, that code can be leveraged by anyone.