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.

Popular

About Carl

Hi, I'm Carl Camera. I'm a front-end web developer and designer.

I've been involved in web development since 1996 helping to launch some of the earliest web applications. Nowadays I oversee development of large websites that are viewed more than ten million times daily.

I think websites should be easy to understand and use. If a website is a source of frustration, it is both a user interface (UI) and user experience (UX) failure. This blog has been created to further the craft of web design and user interaction.

Exploration

As screen resolutions become denser, websites face the challenge of filling pixels without wasting bandwidth.

What you're seeing here are two images specifically tailored both to the size of the slot they are to fill, and the pixel density of the screen in front of you. The dimensions of the images delivered are shown in the second slot. You can alter the image dimensions by resizing your desktop browser or by turning your phone or tablet sideways and refreshing the page.

All images of the photograph are generated from single full-resolution 7712×4352 pixel image – Two megabytes in size. Read more...