A while back I promised I would get around to fully responding to Alastair’s Responding to Adrian, sadly I’m finding lots of little bits of time to blog but not enough time to reply to the whole post at once. Hence, I’ll have to respond in parts when I get time.

First up, the problem that HTML doesn’t render the same on different systems. My assertion is that generally the differences aren’t significant enough to worry about.

This is a pretty broad, and in general wrong, assumption. In my article I provided an (admittedly rather contrived) example where the reader selects boldface type for display, completely obscuring the use of boldface type that the writer had chosen for emphasis.

Firstly I’m not sure I’ve ever seen a user choose to make all text bold, nor can I imagine a case where it would help – larger text definitely, but not bold. That said, there are cases where things will render differently for good reason – screen readers for example render the text as spoken words, rather hard to display bold. Sadly, it’s also rather hard to tell the difference between CITE and italic or even normal text and STRONG. Braille devices suffer the same problems, there’s just no way to display emphasis so that markup is ignored. Should then we all stop using any formatting in our documents because braille doesn’t provide a way to represent it?

The solution is to ensure that the textual content carries the intended message and formatting is used to make it simpler to understand as opposed to making it possible to understand.

Despite being at least vaguely aware of the possible differences that can arise between my system and yours, on too many occasions I have managed to shoot myself in the foot. Like picking an unusual unicode character. Or my various ham-fisted CSS experiments. The point being that I often have no idea about how this site will look on other people’s systems, and it sometimes does make a difference. A big difference.

A WYSIWYG editor has absolutely no impact on whether or not you choose to use unusual unicode characters or mess up your CSS. The fact that these things don’t render correctly in some browsers is because of a bug in the browser1. It is not something you can anticipate with great knowledge of the HTML and CSS standards, it is something you have to find out by testing on all browsers. Which brings us to:

Testing that there are no differences between your editing environment and certain common viewing environments is of course laudable. Extending this to assert that there are no such differences for anyone, seems a bit, well, naive.

Testing in different environments is the only way to be sure that there are no differences. You can use semantic markup all you want and follow the standards to the letter but still have your site not render correctly in any browser2. This also ties back to my comments on Content Authoring vs Site Design. When you’re designing a site you will use complex CSS and pull fancy tricks that are likely to cause problems, when you are authoring content, you really just want to type text, insert a few hyperlinks, a table, a list, an image and some basic formatting like bold and italic3.

…one of my objections to WYSIWYG for editing HTML is that it reinforces the illusion that What You See on your browser is What I Intended You To See. It emphasises a single possible representation of the HTML, and disregards all of the others, thus encouraging the inexpert user to believe that there is only one possible representation of their document. In this respect HTML differs from other uses of WYSIWYG, such as in a word processor.

While it seems logical to conclude that have a WYSIWYG view of the document you’re editing makes people inclined to believe that there is only one possible rendering, that doesn’t seem to be the expectations that users actually come up with. Firstly remember that I work in the work of content editing, not site design. As such, the content that people create with a WYSIWYG editor is merged with other content, has different CSS applied to it and output to multiple different formats (HTML, PDF, Print, etc). This post looks quite different in the WYSIWYG editor compared to its final output format on my blog, not because the HTML and CSS are rendered differently but because a header, footer, sidebar and other blog posts are all added into the final page.

Besides that, even if users begin with the expectation that there is only one possible view of their content, they very quickly learn otherwise when they view it in a browser. Even when the editor uses the same rendering engine as the browser4, the final output looks different because all the extra editing markup is now gone. Things like paragraph markers, dotted gray lines to indicate the boundaries of tables with no border and other rendering all make the content look different in edit mode compared to design mode.

WYSIWYG editors are about making it more intuitive for users to create their content, not about making users be more pedantic about how things look. It avoids users having to learn some foreign syntax and debugging errors in it when they mistype something.

[M]ost people tend to use the I tag instead of EM because they want italic and not emphasis. Any decent HTML editor will use (or at least have an option to use) EM when the user clicks the italic button, thus preserving intent and displaying correctly in nearly every situation.

I’m going to assume that he meant “button” or some UI widget instead of “tag”. By definition WYSIWYG editors do not encourage users to edit tags.

No actually, I meant the I tag. If you make users write out HTML by hand, they will tend to use the wrong tags for things. In most user’s minds, they want to make text italic, they don’t want to apply emphasis because that’s a foreign technique to them. It is a little odd that this occurs when the reason they want to apply italic is for emphasis but italic has been in use in writing for so long that the logical jump has become in-grained into most people. The advantage with a WYSIWYG editors is that you can reverse that mapping for them, when the press the italic button, the editor inserts an EM tag.

There’s also no reason that a WYSIWYG editor can’t let users apply semantic markup when available. For instance, I can apply different heading levels and CSS styles right from my editor, I can use the correct list type, plus differentiate between indenting and blockquote. I can use the CITE, the EM or the I tag as I see fit, or I can change the editor’s configuration and limit what the user can do. For example, I might want to limit the user to just applying CSS styles, so I can remove all the other formatting items off the menu bar. Then all the formatting done by the user will be using only CSS styles that I’ve predefined. I can even change the rendering of different styles to make them visually distinctive in the editor even when they aren’t in the final rendered page.

In short, there’s no reason that you can’t generate perfectly good, semantic markup using a WYSIWYG editor – you just have to find a good one, configure it correctly and train users on what semantic markup is and why they should use it. The training you need to do anyway, but at least you don’t have to teach them the foreign syntax language of HTML and CSS.

My Turn For Snarkiness

At this point I can’t resist pausing to point out that the link to Alastair’s previous ponderings demonstrates quite nicely, the kind of syntax error that WYSIWYG editors were invented to avoid. When typing the link Alastair forgot to being with ‘/’ and thus the URL was treated as relative instead of root relative and clicking the link results in a 404. Of course, with my fancy WYSIWYG editor I can search through my previous posts for specific text, select the one I want and create a link to it correctly every single time.

I should also point out that the problem with tag rendering that Alistair pointed out in my previous posting was actually caused by my hand written code that integrates the editor and not the editor itself. The editor correctly put in an entity reference but in the back end processing to save the entry it got interpreted back to the less than character. I’ll have to get around to fixing that at some point.

1 – For instance IE has a bug which causes it to not render the left hook arrow I use in these footnotes correctly. The HTML however is perfectly valid so it should render everywhere.↩

2 – In fact, the more you ahere to the latest and greatest HTML and CSS standards the less likely your site will render correctly. While CSS might be better in a lot of ways, if you want browser compatibility table based layouts are still the safest bet.↩

3 – Which any decent WYSIWYG editor should apply as STRONG and EM tags↩

4 – As in the case of JavaScript based editors↩