If you use one or more of the billion and seven content managment systems out there, you're probably more than familiar with a what-you-see-is-what-you-get (WYSIWYG) text editor.  These *fun* little textareas allow users to mimic, with decent accuracy, the styles and organization that they would normally apply in word-processing documents.  

The original intention of WYSIWYGs, of course, was to put control of text styling and organzation for web-based content into the hands of the people managing the content, so that every bit of text-editing doesn't have to go through the web developer.  The result, however, is a disaster.

Why a disaster?  Well, before discussing the reasons why, try this little experiment.  The next time you're around a web designer/developer, say nothing to them.  Simply shift your eyes, turn your head, and randomly blurt out "WYSIWYG!!!".  They will either 1.) punch you in the mouth out of built up frustration or 2.) cower in a corner as they are reminded of how they are abused by WYSIWYGs on a daily basis.

So what's the big deal?  

Well, to begin, most content managers have no business even thinking the word "design," much less actively participate in it.  Giving them the reigns to "make the Web look like Word" is an inivitation to a trashed web site because, well, have you ever seen the Word docs they produce?  But worst of all is when a content manager actually fancies herself to be a designer.  The result will be hideous (really, 4 different font colors?!?–how is that necessary?) and will immediately destroy any semblence of order and consistency for which you so painstakingly labored.

But by far the biggest sin of the WYSIWYG is that it breaks down the universality of markup language in favor of a vision-exclusive language.  

HuH?  

In HTML, information is organized through the tags we're all familiar with.  But these tags are more than just wrappers for content–tags like h1's and p's have specific purposes, and their actual usage is intended to communicate something, not just the content which they hold.  So for example, a chunk of text with an h1 and several p's represents a body of text with a heading and paragraphs.

The beauty of this, of course, is that the meaning of these elements is independent of the medium used to access them.  Through CSS, font-sizes, paddings and margins can be applied to each of the elements to visually show the primacy of the heading, and the spacing of the paragraphs.  And for screen readers and other assistive technologies, the division between the elements can be audibly differentiated to give the listener a verbal indication of how the content is structured.  The point here, though, is not how the material is presented (visually, verbally, etc.), but that the information can be processed, from an informational standpoint, in precisely the same way with an equivalent conversion of meaning to the user accessing it.

Bleh, that was a lot of words.  But it's important, because this is precisely where the WYSIWYG's break down.  Unless the WYSIWYG is in the hands of a trained user–and by trained, I mean someone who knows the importance of information structure–the inevitable output will be the garbage of old HTML.  Why is this stuff so bad?  To acheive what users want to SEE, WYSIWYGs move from a being tool for organizing content to being a tool for styling content apart from any relation to the meaning or function of the content.  So instead of the h1's and p's that were crucial to medium-independance, elements like 'font' tags and absolute positionings are used to achieve the visual goal.

Enter vision-exclusive language.  The universal meaning of the content structure is now lost, because what does a "font" tag mean to a screen reader?  True enough, the sighted user can still make sense of the information that is presented.  However, this is only because they can visually make up for what is non-existent in the actual structuring of the information presented to them.  Apart from this visual content, however, the meaning breaks down.  The content becomes one long string of information that can no longer be organized into something usable and comprehensible.  What you see is what you get, as long as you can see.  If you can't, good luck.

Obviously, this is not acceptable.  The web was, is and will ever be meant for universal accessibility, independent of the medium used to access it.  WYSIWYG's destroy this intention and replace it with an alternative that, by it's very nature, is context-dependant.  

So does this mean that WYSIWYGs should be thrown away?  Maybe.  On the one hand, they embody, at least partially, the desire that the web–and production of content for it–should be a universal, not something available only for web developers.  On the other hand, most users do not have a deep enough understanding of the unique requirements of HTML to make good content, and revert to the unrelated (and for this scenario, bad) training they've had with word processing programs.

There is no easy answer.  WYSIWYGs can be very powerful tools in the right hands; the rub is in finding time and training resources to turn content contributers and editor's into these hands.  Nonetheless, the answer should be fairly clear, if not easy: which solution will produce the kind of content that is universally accessible?  If through training and experience, the WYSIWYG can be turned into a tool for this, it's the way to go.  If not, better solutions will have to be found.  Until word processing programs approach content in a similar manner (and they probably never will), it's just something us web developers will have to continue to fight against…but we already knew that :).