Never heard of error reporting for HTML? Well, me neither, but I plan to use it soon…
PHP parse error as seen on a page
For server-side programming languages it is a standard good practice to activate error reporting while you develop something and deactivate it on the live server. That’s for obvious good reasons: You switch them on because you’d like to know about all errors to fix them as early as possible. And you switch them off because normal users of a website or application shouldn’t know about them.
PHP error as seen in an error log
But there’s no such thing for client-side programming or markup languages. There are validators for HTML, CSS and JavaScript, but they are not as convenient because they don’t happen automatically and not instantly with every page request as server-side errors do. The one thing that comes closest to JavaScript error reporting is leaving the console (which is now thankfully part of every modern browser) open all the time to see every error that happens. The thing that comes closest to HTML error reporting is installing some third-party browser plugin which validates the page with every page request. The problem with that is that such a plugin doesn’t really exist. All such available plugins either need you to press a button before it validates or it is very slow or it only works in some circumstances. (Some good, but not sufficient examples are the Html Validator and the Total Validator Firefox add-ons.)
There actually already is an in-built browser feature which will do a majority of HTML error reporting. Or rather XHTML error reporting. What I am talking about is the XML parser.
Why don’t we send the pages as application/xhtml+xml in development mode and as text/html in production mode? Sure, there are two problems with it: It only makes sense if you are writing well-formed markup and make sure you use Unicode characters instead of named entities. (But you do that anyway, right? I personally prefer Polyglot Markup over any other, so it’s easier to switch between doctypes.) And it’s not exactly the same thing as proper validation as it “only” validates the XML part, so the well-formedness, and doesn’t check against any DTD. (Yes, that means the title of this blog post is wrong and misleading, although intentionally so.)
But in my experience the majority of HTML errors which cause problems are exactly those kind of errors, e.g. when a div is not closing somewhere. It’s potentially hard to fix when you discover it later on, but when you see it straight away, it will make things a lot easier.
So, here’s how to do it (in XHTML5 and PHP, other languages will be similarly simple … with “simple” I mean making the switch, not making it validate!):
<?php
if ( stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml") ) {
header("Content-type: application/xhtml+xml");
header("Vary: Accept");
} else {
// this is to ensure you can still test in older IEs
header("Content-type: text/html");
}
?><!DOCTYPE html>
<html lang="en" dir="ltr" xmlns="http://www.w3.org/1999/xhtml">
With the following example code full of errors, you will see helpful error messages like the ones below:
<h1>Not well-formed XHTML</h1> <P> © 2012 Someone & Someone Else <input value=foo readonly> </p>
Chrome renders the page up until it encounters its first error. That user-friendly way lets you at least see some of the page before it stops rendering. The error is also styled in a nice way that won't scare users away.
Internet Explorer 9 also shows the page up until an error appears (similarly to Chrome). The big difference is that IE only shows the error in its console and not on the page!
Firefox is the only one of the major browsers which always stops rendering completely as soon as it encounters an XML error. That's why the error messages are quite scary (and also quite ugly). At least it's very convenient that it shows you exactly where the error is.
I very much like how Opera handles XML errors. It will not stop any rendering unless you have its developer tools open ("Dragonfly"). Then you will see a beautiful page with the error shown within the code. That's more helpful than any of the other browsers (although all of them give line and column numbers). If you haven't had Dragonfly open already, you can either reload the page or just look at its console and you will see the errors there as well.
I wonder if it would be possible to add a piece of JavaScript that takes the current HTML and passes it through the browser’s XML parser and then creates a useful Error report in *every* browser.