Filtering HTML5 Validator Errors

In an ideal world, every web page you work on would have 100% compliance with the HTML5 spec. But in the real world this often isn’t possible. Sometimes we need to add standards noncompliant markup to support certain browsers. We might also be using server-side frameworks which generate invalid markup.

Unfortunately the major HTML validators and¬†don’t care if you would prefer to ignore certain errors. To them, an error is an error is an error. This can make validating HTML markup a real pain. The results page can be full of errors that you already know about and have made a decision not to fix, making it difficult to identify new or unknown errors.

That’s why I have customised to create I have added a JavaScript layer on top of the original validator which filters the results into groups and lets you show or hide various groups at the click of the button. If some of the error messages are about “frameborder” and “allowtransparency” attributes which you have added to iframes to support IE8, just hide them! If your server side framework generates closing <img></img> tags instead of self-closing <img/> tags (I’m looking at you, ATG), hide those errors too! By filtering out the noise you will be able to identify when there is a serious problem in your markup, such as an unclosed element or duplicate IDs.

Below is an example of the validator grouping error messages for Melbourne newspaper The Age. As you could imagine, looking at a list of 17 groups of error messages is much easier to comprehend than a sprawling list of 299 individual errors.

If you would like to use the validator, head over to If you’d like to learn about how it works, read on.

Under the hood, is just with a JavaScript layer added on top. In fact, I haven’t written any server-side code. Fortunately, the good people at have configured their server to send an HTTP response header of “Access-Control-Allow-Origin: *”. That enables the client-side JavaScript on to make Cross Origin Resource Sharing (CORS) requests to the server.

The first CORS request is a simple GET request to load in the form. Most browsers support this – the exceptions being IE7 and Opera. I’m not too worried by this because Opera is expected to support CORS in version 12 and how many web developers are using IE7? Not the ones who would care to validate their markup I suspect!

The form gives the user three main input options: Address (URL), File Upload and Text Field (direct input). Address input is the simplest option and the only one which works in IE8 and IE9. It serialises the form and sends it off as a GET request. When the response is returned, the JavaScript sorts the resulting error messages into groups and generates an interface to toggle the visibility of the error messages in each group.

The File Upload and Text Field options are a little more complex because they have to post “multipart/form-data” in a CORS request. This can be achieved with the FormData¬†object, which is supported in Chrome, Firefox and Safari. IE10 and Opera 12 are expected to support this object too.

The final feature I added was HTML5 local storage to remember which groups of error messages the user has hidden. When they validate another page or return to the website later, their preferences remain intact.

Happy validating!

2 thoughts on “Filtering HTML5 Validator Errors”

Leave a Reply

Your email address will not be published. Required fields are marked *