WYSI(not)WYG

I’m in WYSIWYG hell… and I’m not alone. (For those who don’t know, What You See Is What You Get — the acronym is pronounced whizzy-wig — is a term for any visual HTML editor such as the ones in Web-based email editors, blogs or content management systems. It’s supposed to let you do basic formatting, like bold and italics.)

WYSIWYG editors are great, until they don’t work. Which, lately, has been often.

One of my clients has an older online text editor plugin for their content management system. Problem is, with this editor plugin, what you see is NOT what you get. Formatting is very tricky, especially when I’m pasting text from another source. Even when typing from scratch, there are issues. We’re making plans to upgrade the system, and that should fix some of the problems. However…

Yesterday, I spent about 20 minutes trying to figure out why an entry in this blog (WebBlather) went into bold and didn’t come out of it. Different system, different editor plugin, more up-to-date — still throwing formatting problems. The WYSIWYG editor was showing the text correctly, but when I saved the post, one bold header was making everything else after it display in bold. Fixing it in the visual editor window was useless, since that window displayed everything correctly.

Ugh.

Here’s the problem: WYSIWYG editors display a visual representation of what the HTML code will look like when displayed in a browser. To do that, they create the necessary HTML tags behind the scenes as you type. Sounds easy enough, except for the endless possible scenarios that these tools must cover. Here are a few simple examples.

• Copying and pasting HTML code from another program: if the original code is formatted differently than what the editor uses, how much should it try to fix the pasted code?
• Typing, then using delete or backspace: if you delete all characters in a particular format, should the program keep the format tags in place for when you retype the new text?
• Text formatted with inline CSS versus text formatted with older tags, like [font] or [bold]: should the editor leave the older tags or attempt to convert them to cascading style sheet formatting?
• Clicking at the beginning or end of formatted text: if you click to put the cursor right between plain text and bold text, should the new text you type or paste be plain or bold?
• Microsoft’s many proprietary tags: MS Word and other office programs use an extended set of HTML tags for detailed formatting. Many of these are not part of the HTML standard, but IE reads some of them and other browsers do not. When pasting from these programs, should the editor strip these?

Add to that the many variations with different browsers and browser versions, and it’s a wonder any WYSIWYG editors work at all. And in the case of my client’s CMS, the sitewide cascading style sheets tend to affect the formatting as well… so even if the editor has done its job, the page might still look wonky.

What to do? Most WYSIWYG editors have an “Edit HTML” button. When needed, I go searching through the raw code to find an errant tag or malformed bit of code, fix it, and see if that solves the problem. Some editors have a button to strip all formatting (or strip Word formatting), which can sometimes help — start clean, then carefully add just the formatting you need. And I’ve sometimes pasted code into Dreamweaver (itself a WYSIWYG editor… but better at interpreting code), fixed the formatting, then copied and pasted back into the other editor for publishing.

So even though the WYSIWYG editors have made it easier to publish formatted code, there are still times when they fail, and the old-fashioned solution becomes necessary.