WYSIWYG Editors: Forecast Calls For Continued Suckage
Many folks are trying out the new iWeb application, a WYSIWYG editor for web pages that is new to the Apple iLife ‘06 suite. And it seems many are walking away not impressed with the quality of HTML markup generated.
Many, like John Gruber for instance, point out that, hey, at least it validates as HTML. This is in fact a significant improvement over the famously terrible markup generated by Microsoft Word, and over the standard of WYSIWYG editors in general. Generating halfway decent HTML markup from an WYSIWYG editor is apparently a very difficult task, as evidenced by the number of implementations that generate tag soup. However the pundits say that the redundancy and ugliness of the code can be expected to improve in subsequent releases and I agree.
However when it comes to generating the tags that correctly reflect the intended semantics, I say that this is a task which is beyond the capabilities of a WYSIWYG editor. Without wishing to repeat an already belaboured argument, let me just propose a thought experiment.
Consider the following admittedly contrived sentence:
The raison d’être of of Orwell’s Animal Farm is satire.
Here is one way to mark it up to approximate the semantics intended:
The <i xml:lang="fr">raison d'être</i> of of Orwell's <cite>Animal Farm</cite> is <em>satire</em>.
How would you design a WYSIWYG editor which would allow the correct markup to be applied to that sentence?
In order to satisfy the WYSIWYG requirement you need to use the same visual representation (ie italics) for each of the three types of tag. Hence you need to use some out-of-band mechanism to highlight the semantic difference between the tags. Maybe hovering the mouse over each word would show you the currently active tag. Maybe toolbar buttons corresponding to the correct tag could be selected when the cursor is clicked somewhere inside a tag.
Maybe you could get this stuff to work when you had to deal with multiple, overlapping tags and other corner cases. Maybe you are a better UI designer than I. And maybe you can get it all working with some degree of usability. (If you do, let me know, because I want in :)
Anyway, the point is that all WYSIWYG editors are necessarily hampered by the fact that there are many HTML tags which share a common visual representation, and there are other HTML tags which have no visual representation. So how are you going to edit these things visually? If WYS is WYG, what happens to all the stuff you can’t see?
In the future, WYSIWYM (whoops, of course I mean WYSIWYM) editors will sort this all out, but in the meantime we’re left with editing tags by hand.
0 Comments