Although this post covers a topic often hashed out before, I find it surfaces from time to time. This is my view of it:

A clarification before continuing: we are talking about professional web development. Not necessarily people who need to enter content through a CMS, for example. (Good quality WYSIWYG editors are important for such users, however, which will be the subject of another post!)

For many people, a nice WYSIWYG editor seems like a good idea:

• It offers convenience when creating markup for web pages
• The ability to either drag various controls onto some kind of canvas, or quickly hit a ‘b’ button or choose a font, seems efficient and quick

However, what seems efficient and quick may actually slow down development and maintenance because of things like:

• Poor quality output markup and code
• Inaccessible content
• Excessive output (code bloat)
• Potential cross-browser compatibility issues

The main reasons, I feel, are the following, in no particular order:

• WYSIWYG editors may encourage bad practice
• Developers may lose full control of the output
• Competing requirements for web sites often not achieved through WYSIWYG; WYSIWYG is the wrong paradigm
• A number of WYSIWYG editors rely on Internet Explorer!

What you see may not be what you need.

WYSIWYG editors may encourage bad practice

(X)HTML markup is about the document structure, not how it looks (although this is of course immensely important overall).

Using a WYSIWYG editor might encourage bad practice, if the developer is not already well-versed in web development.

Why your choice of markup is important

Consider a simple example of rendering a list of menu options, running across a page, each option separated by a vertical bar. People often use a div or a paragraph element and separate links with a space and ‘|’ rather than semantically marking it up as a list of menu options (a ‘ul’ or ‘ol’), followed by CSS to float each ‘li’ next to each other and give a left or right border to all but one the first or last item, for example.

If a web developer knows what they are doing, they may be able to use the WYSIWYG editor to quickly write out a bulleted or numbered list in this way. More often than not, it seems, people preferring WYSIWYG editors are those that will not do this. They may be middle tier or desktop GUI developers doing web development, or preferring tools that hopefully hides the details of web development for the perception of efficient development.

As WYSIWYG may be natural for the more mature desktop GUI environment, I can understand such developers expecting to use similar tools for web pages. However, I don’t think that necessarily applies to web pages.

For the web, while the look of a site/page is incredibly important, the different technologies used on a web page serve different purposes. (X)HTML is about document structure; CSS is used for the look, for example.

Who cares about/benefits from semantics?

A semantically marked page makes it more accessible to a wider audience.

One of the powerful things about the web is the ability to interpret the document (i.e. the (X)HTML) in many ways, by many tools (web browsers, search engines, screen readers, etc).

Accessibility is a legal requirement in many countries. Much can be achieved simply by using better markup so that assistive technology can understand and represent the content to their user as accurately as possible.

It is also, to a lesser extent, good for search engines to index your content — think of Google as a blind user! (But note, indexing is not the same as ranking — will clarify this in a later post!)

WYSIWYG editors often provide inappropriate buttons and shortcuts

A WYSIWYG editor doesn’t encourage thinking about such semantics of the markup; if it looks right then that is enough.

Many WYSIWYG editors offer the classic word processor type of icons, ‘b‘, ‘i‘, even the confusing and often unnecessary ‘u‘. These are all presentational even though they are given prominence.

Some WYSIWYG editors do use the more semantically useful strong instead of ‘b’. But, for ‘i’, while most will go for em, cite is often another use for italics. (There are also times when neither em or cite truly represent the purely presentational italics required in some types of text. Toolbars however, rarely offer all the options, or they get cluttered very quickly!)

Developers may lose full control of the output

Some development tools have been notorious for making it difficult for developers to view the HTML source and make manual changes. Microsoft’s Front Page was probably the most well known! Even their Visual Studio 2002 and 2003 were very bad in this area (made it almost impossible to use an XHTML doc type if using the WYSIWYG editor), though Visual Studio 2005 is a lot better (but still not that great — another post will talk about this!)

By their nature, WYSIWIG tools will decide to mark up content in a certain way. Developers will therefore switch to the source view from time to time to correct or enhance things. Some tools (again, older Front Page and Visual Studio 2002, 2003 spring to mind, in particular!) actively change your own changes! I think, to be fair, this is less prevalent in editors today, but many are still using these older ones, so the problem does exist.

(To its credit, ASP.NET 2 comes with something called the CSS Control Adapter Toolkit, which allows you to change how something is rendered. IMO only, it feels messy and a roundabout way to do something that could have been marked up better in the first place. I can see where it could still be used, even for decent initial markup. It is unfortunately mis-named. These adapters should be used to create semantic markup, regardless of whether it is for CSS or not.)

Why do web developers need full control? To have the freedom to create what is needed, to meet the various web page requirements. Also, if using modern CSS-based layout techniques, knowing the nature of the output is important to create optimal code.

Competing requirements for web sites often not achieved through WYSIWYG; WYSIWYG is the wrong paradigm

Seemingly competing requirements of a web site may include the following:

• Cross-browser compatibility (without having to inefficiently code differently for each browser)
• Accessibility (a legal requirement in many countries)
• Search engine visibility (important for many, many businesses
• Fast downloading

The power of the World Wide Web is its ability to provide content to a variety of people, and technology.

Whether it is the web browser, or a search engine, or assistive technology, all these things will access your same content and try to interpret and represent it as best they can for their user. From a business perspective, richer and richer functionality is needed, yet the page always needs to load quickly, so reducing excessive markup bloat can be important.

It is therefore crucial that the underlying markup is sound and semantically accurate (within the current limitations of (X)HTML).

Providing this extra semantic markup doesn’t get in the way of nice visual designs. (Sometimes it can help reduce the code you need to achieve the same designs.)

The perception that WYSIWYG editors will be efficient falls down when thinking about all the time that will be needed subsequently to ‘fix’ it for SEO, accessibility, cross browser compatibility, etc.

When done up front, as part of the initial project, it is much cheaper (and, I find, often without any excessive overhead).

It is the importance of semantic markup, that makes WYSIWYG the wrong paradigm. It is not what you see that is important (from an editor and (X)HTML point of view), but how you mark your content up.

The above menu list example is worth pondering again. A web standards-aware developer, even if they use a WYSIWYG editor, will opt for a bulleted or ordered list. That on its own is not what you will see by default, if CSS is used to lay it out horizontally, as per above.

If a WYSIWYG editor attempts to provide CSS support too, that could help, and a number of editors are now providing sophisticated support for it (e.g. DreamWeaver and the next release of Visual Studio).

To help out, an editor could implement a standards-compliant CSS engine that can continuously update the WYSIWYG canvas as the developer edits it. This would make for an expensive product, potentially! Or, the editor would need to hook into an underlying browser, which leads to the next problem:

A number of WYSIWYG editors rely on Internet Explorer!

There used to be a time when web developers had to suffer developing for Netscape 4 as well as IE. Netscape in those days used to be full of problems. Now, it is mostly IE 6 and below in particular, that are the buggiest browsers when trying to use modern, established standards/recommendations to achieve all the competing requirements.

That being said, many modern web techniques can still be successfully used even with these browsers.

However, for those WYSIWYG editors that try to provide CSS support, using IE 6 or even IE7 as the underlying rendering engine is the wrong approach. You want to develop to standards, not specific browsers. Reasons:

• Of all the modern browsers, IE (6 and 7) have the most CSS and other rendering bugs
• Standards-based development should be tested against more standard compliant browsers first (e.g. Firefox and Opera)
• This encourages better coding practices
• Only then should the problems that mostly occur in IE be dealt with
• This works even when IE is the major browser for the site, because the pain of supporting multiple browsers diminishes significantly if developing according to standards, rather than browsers

Can WYSIWYG for web markup ever be good?

Where web developers know what they are doing, decent WYSIWYG tools could be used responsibly.

But, even if say marking up the simple menu example above as a bulleted list, then what you see may not be what you get if the editor doesn’t support CSS.

Where the editor does have CSS support, if the Internet Explorer 6 (or even 7) rendering engine is being used, then what you see may encourage inappropriate fixes or code that works in the WYSIWYG editor, but then breaks in other browsers, or even a future IE that fixes its numerous current problems!

One the one hand, I hope that future editors will be far better at these things. On the other hand, even if they improve can they improve enough?

Possible reasons why WYSIWYG may become useful:

• Editors should get better over time
• Many vendors are embracing modern techniques and standards
• Many tools are incorporating sophisticated CSS-based techniques and ideas

For example, DreamWeaver CS3 by default creates descendant selector chains when it generates CSS for you, which sounds very powerful. Visual Studio 2008 will try to encourage better CSS rules re-use. These and other tools offer a ton of CSS management capabilities as well as markup support, so that might be quite useful.

A number of editors also provide additional “widgets” out of the box. E.g. menu bars, animation and other visual features, etc. If, after evaluation, these are appropriate for your needs, produces appropriate markup, meets accessibility, search engine and other needs, then it would seem useful to use those widgets.

However, possible reasons why WYSIWYG may still be unnecessary or hamper development in the foreseeable future:

• Ultimately, it is still feels like the wrong paradigm. What you see may not be what you get and may certainly not be what you need
• Developers will still need to know the output they need if they are to address the multiple requirements typical of most web sites
• Writing the output by hand is ever so quick anyway, and not something to be scared of (we are talking about web professionals here, so intimate markup knowledge is assumed)

(HTML is quite limited in what elements you have at your disposal. While not everyone would know every single element and attribute, the common ones are easily remembered when done repeatedly, just like a programmer in say C will remember most capabilities, but occasionally require a reference manual for some more obscure stuff. And despite the limited web languages, as a post at 37signals notes, coding in those limited web languages is quite pleasant. I’d tend to agree. I know many programmers may see HTML/CSS/JavaScript as too low or not enough of a language, and I certainly like Object Oriented Programming, but I agree with that previous post when it comes to web interfaces!)

Will improved WYSIWYG editors help make the “wrong paradigm” issue go away, or diminish as a concern? Don’t know.

Regardless of the direction, knowing the underlying markup will remain important for a long time, I feel. Kind of like how even though SQL has been around for decades, as have tools that can generate SQL for you (e.g. by drawing lines between two tables, entering conditions in some sort of condition builder), serious DBAs prefer to code by hand. Or, although various tools can create C# or Java or other code for you, developers still need to know those languages.

Using open standards on the server side to output open standards on the client side

One thing I have done successfully with ASP.NET (including ASP.NET 2) is by-pass the whole ASP.NET controls mechanism, in effect, overriding the Render() method to transform XML data with some XSLT instead. XSLT is an open standard and offers full control over the output that needs to be created.

This helps to create a very clear separation between presentation logic (the code to process inputs/posts to the page, request services/data from the middle tier, etc) and output construction (i.e. creation of the markup/response to the client).

Although the way you write your presentation logic is dependent on your platform, the output construction is somewhat platform independent. (With object oriented languages like C# and PHP 5 on the server side, the design pattern for the presentation logic code is also highly reusable.)

I have been able to port the same pattern from classic ASP, to ASP with COM+, to ASP.NET and even to PHP with practically no changes to the XSLT (other than the use of the node-set feature or how the document() function might be used, which are typically minor changes).

Of course, this might be overkill for simple sites, or inappropriate for some situations, so will be the subject of a subsequent post.