Carl Camera

Enemies of Valid Strict XHTML: Part 2

In the first part of this three-part series, I outlined the scope of the series. It begins with the goal of valid Strict XHTML and states that the reason so many sites don't produce valid Strict XHTML is because their content repositories are contaminated with non-validating content, generated primarily by end users and content producers.

This leads us to seek a solution that places some sort of mechanism between content producers and the generated markup. For many content management products on the market, this takes the form of a WYSIWYG Editor.

Enemy #2: "Rich" Text Editors

The concept of a WYSIWYG editor fits in pefectly with our stated solution: it provides a mechanism between the content producer and the CMS content respository. These sometimes-called Rich Text Editors could generate valid markup from the input provided by the content producer.

That is, in theory they could.

The WYSIWYG editors in place today for .NET applications are absolutely atrocious in their ability to generate valid Strict XHTML. One particular plug-in has a Microsoft-Word-Like interface. It looks and acts with a familiar feel and has been wildly successful. Unfortunately, it produces invalid XHTML markup despite years of development. Other similar plug-in editors are just as bad or worse.

These editors, however, have been bundled with several CMS and Blog solutions, commercial products, and in-house web solutions. The result of their popularity, unfortunately, is a mass polluting of content repositories worldwide. For those products and apps and owners of those websites, the damage is done; the garbage is in. They can only expect garbage out at this point.

The best these folks can do is try to clean-up the bad input as web pages are generated. This is known as trying to put lipstick on a pig -- it doesn't work and it annoys the pig.


Seek out or develop WYSIWYG editors that generate valid Strict XHTML. Better yet, find or develop a WYSIWYG editor that produces Markdown or Textile syntax code. This way, if the XHTML standard changes, your content can be translated into that standard with changes to the syntax transformer. Or you can abandon the WYSIWYG editor for direct Markdown or Textile entry.

Side Note: I personally consider both Markdown and Textile to be rich text editors. They provide styling syntax that allows content producers the ability to add headings, paragraphs, italics, bold, bold italics, numbered and unnumbered lists, nested lists, blockquotes, and code blocks, hypertext links, images, hypertext-linked images, among other options. Furthermore, they provide text entry efficiency. Creating an italic word is simply placing underscores around the text to be italicized, _like this_. The same is accomplished much more slowly on a WYSIWYG editor with all the movement away from the keyboard, cursor movement, text selection, clicking and replacement of the cursor.


You make some good points. I've found that both Markdown and Textile syntax code is overwhelming to non-techies. I like your idea of a WYSIWYG editor that produces Markdown or Textile.

Shane Shepherd 06 Sep 2006

Shane: Gee, that hasn't been my experience at all. The woman that maintains the Austin Cursillo site, described herself as

The most computer illiterate person I know of. Except for my mother.

I only taught her italics and bold first. Then she asked how to make a link and I showed her that. Then she asked about images. I didn't throw the whole syntax at her to start with. Perhaps that helped.

Carl Camera 06 Sep 2006

That's great. Are you thinking or integrating a custom WYSIWYG editor into VineType?

Shane Shepherd 07 Sep 2006

Shane: My clients seem to be okay with Markdown at this point. Of course, this does not allow them to make big red links as WYSIWYG editors do. But the upside doesn't let them make big red links. If you get my point.

Carl Camera 08 Sep 2006