Regarding the meaning of WYSIWYG, if you wish to take it as strictly exactly what you see is exactly what you get, then there is no implementation in existence which meets that criteria so the discussion is pointless. My discussion is based on the reality of the world today, not theoretical arguments and definitions. If you wish to substitute the term WYSIWYG with some other that essentially means “presents a graphical view of the document which allows the user to avoid using a markup language” then perhaps you will see my point of view better.

I think Richard has summarised pretty nicely the differences in our points of view.

You make some claims about the potential for WYSIWYG that I think are simply excluded by the definition of WYSIWYG. I’m pretty sure I’m not alone in my thinking either: check the Jargon file or Wikipedia for the WYSIWYG entries. They each touch on the limitations of WYSIWYG with regards to the fidelity of rendering print documents. The same argument is multiplied manyfold when discussing HTML rendering.

On the subject of my broken link (fixed now, thanks): I would challenge you to come up with a) an example of a WYSIWYG editor which would have automatically warned me about a broken link, and b) a reasonable definition of WYSIWYG which would include this warning function as a necessary requirement. The link checking procedure you described (such as it is) could be performed with any half-decent non-WYSIWYG text editor.

I think you and I (and Alastair) are using a different definition of WYSIWYG (What You See Is What You Get) here: you seem to talk about it like its simply a (grammar checking) GUI based editor. Alastair and myself talk about it as (foremost) a rendering of what you expect to see when a user sees it. Think Frontpage, without the code view or the old edit window. Of course, that doesn’t mean that a WYSIWYG editor can’t provide other views for displaying the content being edited: Word does this with its outline and ‘normal’ views. But these views are decidedly not What You Get: in normal view, you don’t get to see inline images. In outline view, even basic formatting is hidden. All vies support showing hidden text, but this is now quite a hard feature to find in modern versions of Word, and by its very name isn’t a WYG feature.

You can’t by definition have a WYSIWYG editor that renders differently depending on the CSS applied to it. The editor must bind the styles to it, in order to be what the user expects. The default font that the user has configured in their browser could easily not have a bold variant, making all bold text look rather plain. It is also extremely difficult to tell by looking at rendered output whether you’re looking at an indented p, a blockquote or something more exotic. All of these can render the same as each other, and correcting one to be the other means stepping outside the What You See part and into the What You Can’t See part.

Regarding making a semantic editor using any good WYSIWYG editor, doing so should be a highly profitable exercise, if only there is a meaningful way to automatically render arbitrary XML schemas (in the general sense, including DTDs, RelaxNG, XML Schemas, and not-even-really-defined like Ant). Unfortunately, this is a harder problem than natural language systems since it requires the machine attaching some meaning to a fragment of text, and then displaying that to the user meaningfully as well.