How useful are WYSIWYG CSS editors


Taming the WYSIWYG editor made easy

Many web workers do not particularly like WYSIWYG editors in content management systems because, on the one hand, they allow website editors too much design freedom and, on the other hand, they do not always produce error-free HTML. Michael van Laar shows how the WYSIWYG beasts can be tamed.

WYSIWYG editors seem to be the natural enemies of web standards-oriented web workers. The little helpers that are included in almost every modern CMS not only give inexperienced website editors a cornucopia of tools for the »creative« design of their texts. After clicking the save button, they also repeatedly generate HTML code that brings tears to the eyes of web standards advocates. Anyone who cannot or does not want to rely on HTML abstractions (for example textile or markdown) as an alternative to the WYSIWYG editor in customer projects must tame the WYSIWYG monster.

The challenges

Customizing a WYSIWYG editor is primarily about these four challenges:

  • Customers should not be able to reduce the design of the website to an absurdity with particularly »creative« designs.
  • Everything that is creatively permitted, customers should actually be able to implement with the WYSIWYG editor without being hindered by technical restrictions.
  • The representation of the texts and images in the WYSIWYG editor should correspond as closely as possible to the final representation on the finished website.
  • The HTML code generated by the WYSIWYG editor should be error-free and as far as possible semantically correct.

The technical implementation

This article is mainly about What We as web workers can do everything to make working with a WYSIWYG editor more pleasant and safer for our customers and for ourselves. Precise instructions, how if these adjustments can be technically implemented for all common editor-CMS combinations, it would unfortunately go beyond the scope of this Advent calendar article. Googling helps.

Step 1: tidy up button bars

First we button the button bars. The widespread editor TinyMCE, which is particularly "popular" with web workers, serves as an example. The standard configuration of the button bar, which varies depending on the CMS, is usually not optimal.

The optimal configuration of course always depends on the website, the editors and the editor used. The rule is: as few buttons as possible, as many as absolutely necessary.

The following buttons or drop-down fields should also be activated in any case, if this is not the case in the standard configuration:

  • Selection of predefined CSS classes (similar to the format template selection in word processing programs)
  • Superscript, subscript (especially for websites with technical or scientific topics)
  • Find / replace
  • Insert non-breaking spaces

These buttons, on the other hand, usually have no place in the button bar:

  • Free change of text color, font, font size or other attributes that should be reserved exclusively for the stylesheet
  • Underlined
  • Justified
  • Embed / edit multimedia
  • To press

A good button bar also takes user habits into account. The arrangement of the buttons in the following screenshot is based, for example, on the familiar Microsoft Word 2003 program interface.

By the way, WordPress users can easily customize the button bar with the help of the TinyMCE Advanced plugin.

Step 2: clean up block formats

In the selection field for the text block formats, only those HTML elements should appear that are actually allowed to be used by the editor. An example: If the main headline of a content page is automatically filled (for example via a »page title« field in the CMS), only headings from the third level should be available in the selection list of the WYSIWYG editor. That already minimizes the risk of incorrect headings nesting by the editor.

In addition, web designers should check carefully whether it is actually absolutely necessary that CMS users are given the option of inserting semantically meaningless containers using the WYSIWYG editor. If not, get rid of it. What is not there cannot be mistakenly clicked on in the selection list. Experience has shown that for many websites it is completely sufficient to allow two heading levels (for subheadings) and, if applicable, and in the block format selection field of the WYSIWYG editor in addition to the element.

Step 3: Define style templates in the form of CSS classes

As a rule, website editors should not be able to freely change design attributes such as text color, font or font size. The risk of a design that does not conform to the corporate design or simply looks bad is high. So that editors can work effectively with the WYSIWYG editor despite these restrictions, it is necessary to provide all the required design options in the form of CSS classes. Each of these CSS classes can then be assigned a meaningful entry for the selection menu in the editor via the configuration options, which are designed differently depending on the editor and CMS. However, as part of the introductory training course, editors must be made thoroughly familiar with this "Format template" selection field and the templates it contains. After all, not everyone uses the format template function of their word processing program, although it is practical.

Step 4: Create text modules for complex designs

Most WYSIWYG editors offer the option of providing text modules. This option can and should be used to support website editors with design tasks that would actually require knowledge of HTML. Most WYSIWYG editors offer tools for creating tables. However, it is not always easy to come up with an appealing-looking table with semantically correct HTML code using only these on-board tools. It is better and safer to use the text module function to provide a pre-formatted, empty table for the most important table basic forms. On this basis, it is much easier for editors to achieve the desired goal.

Again, the TinyMCE is used as an example. The »templates« plug-in takes care of the provision of ready-made code snippets. Web workers can name individual HTML files in the editor's configuration files, each of which contains a text module. Meaningful titles and descriptions for the text modules can also be assigned. The TinyMCE documentation contains detailed instructions for this. After activating the plug-in and inserting the corresponding button at the desired location on the toolbar, users can conveniently view and insert the pre-made code snippets using a pop-up window.

Step 5: Customize the presentation of the content

Not every installation of a WYSIWYG editor lives up to its name. In order for users to actually see in the editor window what they will later get on the finished website, the display must be adapted. This is done using a separate stylesheet in which the web designer collects all CSS definitions necessary for the editor display. Unfortunately, for various reasons, simply linking to the website's "normal" stylesheet doesn't usually work. But the additional effort is worth it. Many layout questions that can otherwise only be answered with a preview can now be solved directly in the editor while editing.

Tip: In the case of layouts with fixed widths, it is advisable to give the outermost container of the editor content (for TinyMCE, for example, this is called the width of the later text column). In this way, all breaks and element arrangements appear exactly as they will on the later website.

Step 6: prevent HTML errors

The TinyMCE in particular is known and feared for the crude HTML constructs it sometimes produces. Modern WYSIWYG editors usually have an internal error correction that is supposed to avoid incorrect HTML output. But this does not always work reliably. Additional tools such as the HTML Purifier can help. The HTML code generated by the WYSIWYG editor is checked again for errors and cleaned up. Depending on the configuration and the CMS integration, this happens either before the storage in the database or directly before the output of the page requested by the browser.

What sounds very good in theory does not always produce the desired results in practice. The combination of TinyMCE, HTML Purifier and MODx Evolution, for example, repeatedly creates unwanted cryptic characters in the text. Before using such an HTML guard, it should therefore be tested in detail so that there are no unpleasant surprises at the customer's site.

Painting (detail): Friedrich Herlin, The Apostle Petrus, 1466. Rothenburg ob der Tauber.