Enemies of Valid Strict XHTML: Part 3

06 Sep 2006 by Carl Camera

In the first two installments of this three-part series, I set the goal of producing valid Strict XHTML, then discussed the problems and pitfalls that lead to non-validating websites. I explained that a content repository containing non-valid XHTML is the cause of most non-validating sites. I called out two pathways that allowed non-validating XHTML to enter the repository as the first two enemies of non-validating Strict XHTML.

In this final installment, I present the final "enemy" and root cause for non-validating sites.

Enemy #3: The Architect

Ultimately, the responsibility for invalid XHTML output in a web app lies with the project architect. The architect understands how data will flow into and out of the web application. The enemy, more specifically, is the unknowing or apathetic architect. Ignorance is excusable, apathy less so.

Someone approved the WYSIWYG editor plug-in. Someone allowed -- knowingly or unknowingly -- the ability for invalid XHTML to enter the repository somehow. If your site is producing invalid XHTML, then the architect is, ultimately, to blame.

What Can Be Done?

The solution is simple: Don't Let Garbage In.

You must guard your content repository from non-validating content. Be strict about what is allowed into your database. Vine Type does this in three ways:

Markdown. Markdown is a text-based rich text editing syntax. With simple email-like notation, Markdown is able to style text in a variety of ways and produces wonderfully symantic markup. Much thanks to Milan Negovan for porting this to the .NET framework. I'd like to see Textpattern syntax moved to the .NET framework as well.
Restrict anonymous entry. Content producers can be held accountable for invalid entry. Anonymous editors are never accountable. Vine Type allows only Markdown input and defeats any attempt to enter raw HTML by site visitors.
Validate before persisting. Before Vine Type saves any text content -- whether from the site administrator or a site visitor -- it first runs the text through the Markdown transformation and loads it into an XmlDocument object. If the transformed markup is not well-balanced XML, then the update is not saved and the user is asked to adjust input.

Is Vine Type perfect? No. As a matter of fact, Vine Type allows raw XHTML entry. This decision (as product architect, I take responsibility) is based on the fact that Markdown does not do everything. There are many instances, such as adding a Google Map, that requires raw XHTML entry. Vine Type will validate well-formedness of the XHTML, but it does not detect, say a div element inside a span element.

Nevertheless, the checks within Vine Type have allowed this site to grow to over sixty pages of error-free valid XHTML 1.1. The Vine Type site is approaching 200 pages of error-free valid XHTML 1.1 as well.

Conclusion

Any web application that can serve up valid Strict XHTML can also serve up non-validating XHTML. Keeping the content repository free of non-validating markup is key to success. With some forethought and web-standards compliant content entry tools, architects can guard the content repository from contamination with a variety of tools and validation checks. It is possible to create error-free valid Strict XHTML websites.

Show