HTML Validation: Let Your Browser Be The Markup Validator!

Here's a quick article on XHTML conformance. Learn how to serve your pages in ASP.NET with another content-type to make your browser stop on any parsing error.

Read on!

Table of Contents

• Introduction
• Downsides of Incorrect Markup
• "Real-Time" Validation
• A .NET Example (Tested on Chrome and Firefox)
• Conclusion

Introduction

As a back-end architect and developer, I always dreamed about being on par with the front-end guys. That means having a strict compiler not letting you deliver your work until you did what you had to do and until "it compiles". Now there's a way to even things up! Sure there are XHTML/HTML validators out there to verify the integrity of your documents notably the W3C validator, but this is post-validation and it's often too late.

Downsides of Incorrect Markup

There are a gazillion of reasons why we should validate our documents. But I'll only tell you 2 (my favorites):

1. The DOM is more predictable across browsers
2. It actually makes you think about what you're doing

Number 1 is pretty obvious. The W3C publish recommendations about how to define, parse and render an HTML/XHTML document. But there are no recommendations on how to process invalid portions of documents. That being said, the same invalid code will probably be interpreted by browsers differently since they have their own way of recovering from errors. Now what if you navigate across the DOM in JavaScript in an invalid document? Number 2, to me, is pretty profound. I won't go in details but let's say I just don't like the "trial and error" way of coding :)

"Real-Time" Validation

So what's the big deal? Well, thanks to a co-worker (again the envelope guy), I read something about XHTML validation in the excellent HTML5 book DIVE INTO HTML5 by MARK PILGRIM. I have to give all credits to Mr Pilgrim on this one and I'll make the story short so you can read his book after my article ;)

So the story is that XHTML appeared along with a new MIME: application/xhtml+xml. This MIME instructs browsers to enforce validation just like it is an XML document: completely fail on error. We do XHTML today but we still uses the MIME text/html when delivering our documents so the browser continues to be permissive. Mr Pilgrim states in his book that nearly 99% of web sites aren't XHTML compliant so this is the reason why the transition to the new MIME did not occurred.

A .NET Example (Tested on Chrome and Firefox)

During development, why don't we swap the MIMEs so we can immediately catch XHTML markup errors? It's something I'll explore myself! Here's an example:

In a .aspx page put:

<% Response.ContentType = "application/xhtml+xml"; %>
    <div>
        <p>I love Mike's Blog!</p>
    </div>

It prints:

I love Mike's Blog!

Now in the .aspx page put:

<% Response.ContentType = "application/xhtml+xml"; %>
    <div>
        <p>I love Mike's Blog!</div></p>

It prints:

This page contains the following errors:

error on line 19 at column 31: Opening and
ending tag mismatch: p line 0 and div
Below is a rendering of the page up to
the first error.

HURRAY!

It doesn't seems to work on IE though (only tested IE7, the page refuses to load). Maybe during development if you want to use this "feature" you can conditionally send the proper MIME according to the browser (and always send text/html in production). Just thinking out loud here. Anyways, this is XHTML validation in real time no?!

Conclusion

You saw that is possible in real time to truly be strict when it comes to XHTML markup correctness. Will you use it? What's your situation? Please tell me your story...

I'm putting time and effort on this blog and having you here is my reward. Make me feel better and better everyday by spreading the love with the buttons below! Also, don't hesitate to leave a comment. Thanks for reading!

See ya