My standpoint on WYSIWYG

This document is to explain why WYSIWYG editors are almost always evil by nature, and why almost everyone should stay away from them.

It should be noted well that this document, while it does occasionally build upon subjective premises and some subjective overtones, is not a mere description of the author's opinion. Most of the conclusions drawn are purely rational in nature and thus objectively correct. Please bear that in mind while reading. If you have any objections on any of the conclusions, please let me hear from you about them.

The history of WYSIWYG

WYSIWYG, or "What You See Is What You Get" was, to the best of my knowledge, born and popularized by Apple Computers in the eighties. It is a concept that says that what one sees on the screen when one edits, for example, a document is exactly what one will see when one prints it out or hands it to someone else.

It was indeed the natural evolution of things, since, at the time, most computer-edited documents were written in formatting languages like ROFF or TeX, in which one would insert codes to apply formatting upon a document. For example, a piece of a document written in standard -mandoc-style ROFF could like like this:

.SS user
.TP
Syntax
\fBuser\fP \fIusername\fP
.TP
Description
Initiates the authentication progress. The daemon will call PAM to
authenticate the user specified by \fIusername\fP.
.TP
Privileges
The user must not have the \fBdisallow\fP privilege.
.TP
Responses
See the 2xx and 3xx responses of the \fBpass\fP command.
.br
\fB430\fP - The PAM library would not initialize.
.br
\fB501\fP - The arguments are either missing or illegal.

Obviously, this is not what the final document would look like - there are some different formatting codes in there. For example, .br means a line break, \fB means to print the following text in a bold font, while \fP means to print the following text in the plain font. .TP means to begin a paragraph where the first line is less indented. Ad nauseam.

These languages were invented in a time where users sat before text-only teletypewriters and simply would not be able to see what their documents looked like - their terminals could not display that. It had a great many practical problems, not least the fact that one would have to preview the document somehow to see that one had gotten all the codes right and half the document was not bold because they had missed a \fP somewhere along the line of writing. The user would either have to go back and forth between a previewer program and the editor or print it out once in a while to check it for correctness. Thus came WYSIWYG, where the editor and the previewer were more or less one and the same program, and which also made sure that the preview on the screen would be exactly what would be printed on paper.

Please do not interpret the above paragraph such that I would mean that these formatting languages all bad. More on that later.

Examples of current WYSIWYG editors include Microsoft® Word® and OpenOffice.org Writer. WYSIWYG is not all about document processing, however. It also includes image manipulation and many other things, though this document will focus on the document processing aspects.

Why WYSIWYG is evil

Let me begin by stating that WYSIWYG is not evil incarnate by design - there are aspects where it is useful and good, even the best way of accomplishing the task at hand. However, these uses are comparatively speaking rare, and the vast majority of people who use WYSIWYG document processors daily are wrong in doing so.

So why is WYSIWYG so evil? The reason is that WYSIWYG (and also, please note, the formatting languages described above) focuses primarily on the appearance of the document. However, while writing the vast majority of most documents, appearance does not matter at all - what matters is the content of the document. The appearance only matters once someone reads the document, and that is what makes up the problem, since documents edited in a WYSIWYG editor by design look exactly the same whoever reads them, wherever and on whatever device. I will give a few examples to demonstrate why this is bad. Not all these examples apply cleanly to WYSIWYG editors but rather to formatting languages as described above, but the reasons both are evil are the same, so the examples still apply.

• Imagine a company that has a standard on the formatting of documents (which probably includes most, if not all, companies). All employees use a WYSIWYG editor (a likely real-world scenario would be that all employees use Microsoft® Word®), and adhere strictly to the formatting standard. Then, one day, the company's PR department decides that the formatting standard is out-dated and should be modernized. That means that all documents still in use that were written according the former formatting standard will have to be reformatted from scratch, manually, which would, of course, be a very daunting task for virtually any company (imagine, for example, a product manual covering more than 1000 pages and the task of reformatting it).
• Imagine that a company uses a two or more different formatting standards depending on with whom they communicate - that can be for rational reasons, since an international company might find that some countries might find one formatting standard close to vulgar, while it may be the most pleasing standard for another country. If they then wish to cooperate with associates in several countries on one document, or want to send the same document to several countries, it would have to be manually reformatted all the time, which would be incredibly inefficient.
• Imagine a hobbyist web designer who writes all his/her web pages in old-school HTML, using lots of tags like <B>, <CENTER> etc., and tables for layout. Since he/she is a playful hobbyist, he/she likes to play with different designs, and changes the design every once in a while, although the content of the page remains the same. Since this kind HTML couples formatting with content so closely, the web designer ends up more or less rewriting the whole content just to redesign the page.
• Imagine a web page written in a WYSIWYG editor such as Microsoft® FrontPage®. People will be viewing this web site - that is why it is on the web. However, no matter how much the web designer liked the design, there will be people who do not like the design. For some poorer web designers, there will be more people who do not like the design. However, since the page was written in a WYSIWYG editor, they are stuck with it no matter what.
• Imagine another web page written in a WYSIWYG editor. The page might be of interest to a large audience, not all of which will read the page on a display that is capable of rendering graphics. For example, some UNIX/Linux users might need to download a driver to get their X server (which provides the graphical display on these systems) working. Also, many system administrators access their servers over text-only connections (such as SSH), for very good reasons - they will be unable to view graphics over these connections. Others simply prefer text displays (yes, there are good reasons to do even that). However, the page, which is easy to read on a graphical display, may well become garbled on a text-only display, since it relies on graphical layout elements, images for displaying/aligning content, etc. It will be very hard for these users to read the page. An extremely similar example is that someone tries to read the page on a cellular phone or a palmtop computer, which has a very limited screen resolution. Since the author of the page used formatting elements which place a minimum restriction on screen resolution, these people may become more or less disabled from reading the page at all.
• Imagine that a student writes a report which he/she wishes to publish. When handing it to the school, it must be formatted by the school's formatting standards, but when publishing it, the student wants to format it in a way that he/she actually likes, and ends up having to reformat the entire report from scratch.

These were just a few examples - there are hundreds more, some of which are only a little annoying, while others are major show stoppers. They just go to demonstrate that there are fundamental problems with WYSIWYG editing and formatting languages in that they tie content with formatting on a very low level.

Please note that, as I introduced this section with, there are indeed tasks that are best done with WYSIWYG editors. One of these are pseudo-documents that need to be exactly formatted, such as advertisements. Repeating myself, however, these uses are very rare when compared to the number of uses where WYSIWYG is not just unnecessary, but pure evil.

Semantical markup

The solution to the problems outlined above is called semantical markup. The essence of semantical markup is that instead of specifying the presentational attributes of text, one would specify the actual meaning of the text. Using semantical markup, one does not even think about the final formatting of the document while writing it. The document is then formatted automatically once someone reads or prints it, using a set of rules that describes the formatting (for example, style sheets for HTML/XHTML). For example, in a WYSIWYG editor, one may specify that a piece of text is bold in order to emphasize it, while using semantic markup one would just specify that that text should be emphasized. Another example could be that one, in a WYSIWYG editor, centers all headings, while using semantic markup one would simply specify that the affected text is, in fact, a heading. Or, in a WYSIWYG editor, one would insert the company's logo at the top of each page, while using semantical markup one would not care about that at all - it would be added later by the formatting rules.

There are only so many advantages to this way of authoring. For one thing, one never has to think about formatting standards or anything even remotely close to it while writing the document. One will however have to keep in mind what one actually wants to write, which is probably a good thing when everything comes around. Further, the formatting rules are modular and easily replaceable, which solves all the problems outlined above. If the PR department wishes to change the formatting standard, they only need to write a new set of formatting rules, and all existing documents can just be left as they are, no work required. It is easy to use one set of formatting rules for displaying on a graphical display, another for displaying on a text-only terminal, a third to display on mobile devices, a fourth for printing a hard-copy of the document, ad infinitum, while the author does not need to be concerned with that at all. HTML/XHTML/XML already has this figured out with @media rules in style sheets. It should be noted well, that an author does not need to concern him- or herself at all with formatting standards while writing documents with semantic markup, since all kinds of formatting are applied later on using the formatting rules. Thus, when starting to work at some company, one would not have to familiarize oneself with the way that the company wants documents to be formatted.

To the best of my knowledge, both Microsoft® Word®, OpenOffice.org writer, and surely many other editors like them, already have semantical markup capabilities. However, these editors are still evil, since they are very WYSIWYG-centric. I wish to very strongly emphasize the point that any editor which at all has a bold button or anything even remotely similar (that is, anything which is at all related to the actual presentation of the document), is evil by design. The reason for this is that people who are not very used to the ways of writing documents are easily spoiled by WYSIWYG editors. They can rely purely on instincts (their aesthetical sense) while writing documents - they format the document in one way and submits it to their aesthetical sense to see if it looks good, and if the aesthetical sense returns that it does, then they think all is fine, otherwise they reformat it and repeat the process. Without having been presented to an alternative to WYSIWYG editing, one easily gets stuck in this way of thinking, instead of learning the actual structure of a document, which is also in itself a bad thing.

It is to be noted that semantical markup is not a future technology. It is very real and very current. XHTML Strict, which this document is written in, is a semantical markup language, which uses CSS as its language for formatting rules. Check the source of this page to see that it never once makes any suggestion on how the document should look like, only the semantics of different parts of the text, such as paragraphs, headings, emphasis, etc. The actual look of the page is left purely to the style sheets, which can both be modularly replaced, or modified by the reader him- or herself. It is also readable in text terminals, mobile devices, and if you print a hard-copy, the banner at the bottom which points to XHTML/CSS validation will not be printed. Even better implementations of semantical markup would be DocBook XML and many other XML dialects.

Semantical editing

One of the problems with semantical markup for widespread adoption right now is the lack of GUI editors. I do not know of a single GUI semantical editor (if there is one, please tell me about it). Thus, authors are again left with text-based markup languages, such as XML, for semantical editing.

While this is a problem for many users, I do want to stress that it is not a completely bad thing. Text-based languages do actually have advantages before GUI editors, contrary to what many seem to think these days. For example, they do not hide anything from the author - the author just can't miss it if he/she has erroneously specified some attribute that a GUI editor would normally hide. Of course, that advantage can also backfire in that one is more or less bombarded with information that is often not absolutely necessary. Moreover, text-based formatting languages explicitly hide any formatting from the user, which can well be an advantage, since the user cannot be aesthetically dismayed with the apparent presentation of a piece of text while editing, which could well trigger such an illogical response as wanting to choose an erroneous semantic meaning for the text just to make it pleasing on-screen (which has historically happened very much in HTML editing, when people have been using <H?> tags (which are really used for headings) for formatting purposes).

Still, text-based markup language input does have its drawbacks, not least re-introducing the need to preview the document every now and then to make sure that one has gotten all the codes right. Also, markup languages such as XML are also fairly hard to edit, since many codes are long and tedious to write all the time. What I want to state is not that text-based input is superior - just that it is a way of input that is not to be overlooked. Some people will prefer text-based input, others will prefer graphical input.

Conclusion

The conclusion of all this can only be one - WYSIWYG editors should all be deleted from all but all computer systems. If you are still not convinced about that, please let me hear from you with your reasons as to why.

This site attempts not to be broken.