Falling back to HTML markup really isn’t much worse than falling back to wiki syntax in a few rare cases, and if it were really a problem you could fallback to a FireFox specific WYSIWYG editor (ie: the built-in features that FireFox has). Yes that would take more effort, but the benefit to users and the improved adoption of the system should justify it for a heck of a lot of cases. Of course it probably pays to run the content through Tidy to clean it up if it’s come in from hand-editing so that it’s cleaner for users to see (apparently unlike with our demos).

Also, I’m not sure what browser you’re using, we support the widest range of browsers and OSs of any WYSIWYG editor that I know of so it’s unfortunate that you don’t use a supported browser. For our particular market that’s not an issue because we tend to sell to the enterprise where they use a standardized browser or a small number of browsers and platforms.

It’s really important to stress that users should never have to see raw markup in any form. If they do you have a problem with your system. It should be displayed and edited as WYSIWYG, so being harder or easier to read is totally irrelevant.

You’re right that Wiki syntax is easier to clean of cross site scripting attacks, but there are existing tools to strip JavaScript from HTML so it’s not that big a deal. It also depends on your target market - JavaScript is explicitly allowed on our internal wiki and used to great effect but that’s with a controlled set of users who get fired if they try to break our systems - social control rather than technical. If you have a publicly available wiki you need to be more concerned about it but it’s still not that difficult. I’m sure the Daisy developers have already confronted this problem, just take a look at their code.

By the way, while a WYSIWYG editor can probably be configured to prevent a user entering JavaScript you shouldn’t rely on this because I could POST a JavaScript containing document directly to the server and by-pass the inherently client-side editor. Never rely on client side validation.

Finally, there are a lot of crap WYSIWYG editors out there but for non-geek users (ie: not you and probably not any of the readers of this site) they are almost all better than having to edit any syntax by hand. Besides which there’s so much choice out there that you should be able to find one that suits your users. Don’t forget to spend the time configuring them too!

Also, it’s worth noting that a Wiki syntax doesn’t have anywhere close to the same level of complexity for preventing cross site scripting. Simply escape the three evil characters anywhere they occur in the text, and you’re done. No need to worry about whether the user is trying to indicate that something is less than another thing or if they’re trying to open an HTML element, or which tags and attributes are OK and which are not. Again, a WYSIWYG editor can take care of this for you, I expect.

WYSIWYG editors have plenty of upsides, but the downside is, frankly, most of ‘em suck to use. Maybe the ones Ephox creates are better… but “This system does not meet the minimum requirements to run EditLive! for Java. Now using a textarea instead.” The fallback position for a WYSIWYG editor is generally substantially worse than any Wiki syntax, or even hand edited HTML, because generated HTML is rarely readable.

Thanks!

We solved the problem of text-based diffing using a custom (server-side) “HTML cleaner” component which gives a byte-for-byte equal result whether editing happend in IE or Firefox (the HTML these produce can be quite different) or as source. This includes doing things like switching to a new paragraph when encountering two br’s etc. See for example here:
http://cocoondev.org/daisy/index/version/6/diff?otherVersion=7