Content Editors and HTML Structure
Posted by Andy Tyra - Dec 08, 2010
We've tried our many of these editors throughout the various iterations of our CMS. We started with FCK editor, an editor that began being widely used in 2007 and developed a huge user base. The toolbar on the FCKeditor was packed with features and options including the ability for users to change the font, text size and color among other attributes. It also allowed clients to add tables, links and other elements to their content. It was a veritable wonderland of formatting fun.
But like Spidey always said: with great power comes great responsibility. We discovered that when clients used certain formatting options, the result was poorly structured HTML markup. If a client changed a paragraph's font, color, text size, and then changed it again, the result was a long series of and tags wrapped around the actual content. The more they changed and rechanged, the worse it became.
This was bad for a few reasons. The first reason was that the content would display in an unpredictable way. Different browsers would render the nest of tags in different, sometimes unusual, ways. The second reason was that clients formatting their content couldn't figure out how to undo what they had done using FCKeditor; that is, even the FCKeditor itself couldn't sort through the nest of tags it had created. We found ourselves troubleshooting pages that were appearing incorrectly due to the mess of extra tags. The last reason was that these extra tags inhibited good search engine optimization. Search engine bots (or "spiders") would have to weed through a pile of extraneous tags before they got to the indexable content--and because these bots only index at a finite number of characters on any given page, they might not make it through the pile.
So we decided to change to a different content editor with fewer options. We chose TinyMCE. This was a good content editor--but it had it's own set of drawbacks. Some clients reported bugs. Other clients with older browsers (IE5.5 and IE6) reported that TinyMCE didn't work at all.
So we changed once again to WYMeditor: an editor that was more consistently stable, had a limited set of formatting options and created clean standards-compliant HTML structure. We thought we had arrived at the best solution.
We discovered that clients/users that used WYMeditor didn't like the limitations. It required that clients/users knew how to code CSS and HTML markup for things like floated alignments, tables and other more advanced content formatting. Additionally, WYMeditor didn't allow links that open in a new page (target="blank") or the embedding of YouTube Videos, Google Maps and other code snippets in the content area. Clients/users wanted more options.
So this is our dilemma. Do we ignore good HTML structure and give clients/users a sophisticated content editor that resembles a word processing application? Or do we limit their formatting options and force them to create standards-compliant code?
The best answer is somewhere in the middle. We'd like to give our clients and the users of our CMS as much control as possible but also educate them on the importance of good HTML structure and encourage them to consider it. There is a great article by Nick DeNardis on this topic.
"Itís not just about making the page look pretty but the actual HTML behind the page has meaning. The initial thought when charged with updating or maintaining a web page is to initially write up the content in Word, get everything finalized, approved and then copy and paste it into the content management system (CMS). This is a great process but a lot may get lost in the translation from Word to HTML."
Things have come full circle. We are planning to return to a more full-featured content editor like CKeditor (the newest open source editor from the creators of FCK editor) but we will remove from the content editor's toolbar those buttons that result in poorly structured HTML pages.
We're also going to improve our dialogue with clients and content managers about good HTML structure.