Forget WYSIWYG editors - use WYSIWYM instead | 456 Berea Street

A huge problem with almost every CMS in existence is the extremely poor quality of the code produced by their WYSIWYG editors.

Highlighted by sandge

Since visual gadgetry like WYSIWYG editors sells, every CMS has to have one.

Highlighted by sandge

That, in turn, makes it necessary for Web professionals who want to reduce the risk of clients unknowingly ruining the website’s semantics and accessibility to disable features and implement more or less advanced code cleaning procedures. It is a mess.

Highlighted by sandge

Because of the problems caused by WYSIWYG editors I have toyed with the idea of providing a much simpler interface for content editors. Markdown, BBCode, and Textile are a few possible solutions that ensure valid markup and increase the likelihood of it being semantic. The problem would be making clients accept working that way, directly editing pseudo markup. Most clients wouldn’t, so that option is ruled out.

Highlighted by sandge

But there is another kind of editor that is better suited than WYSIWYG for content-driven, client-edited sites - the WYSIWYM (What You See Is What You Mean) editor. In Visually Editing Semantics - What You See Is What You Mean, Peter Krantz mentions one such editor: WYMeditor.

Highlighted by sandge

From the WYMeditor site:

Our goal is to create a XHTML strict web-based editor which will be usable on many platforms, whith the help of the Open Source Community.

Highlighted by sandge

There are a few limitations, of course. This is an early version, after all. Besides the issues Peter notes in his post about WYMeditor, here are a few more things I noticed:

• Table accessibility. There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables.
• Table resizing. It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database.
• Incorrect nesting of lists. When you create nested lists, the current list element is closed before the next level ul or ol is inserted.

Highlighted by sandge