Je tiens aussi à vous dire un tout grand et retentissant merci !
Par rapport à ce que jf_h a déjà dit, je souhaiterais développer quelques points:
L'approche de WYM editor, qui consiste à faire abstraction de la présentation finale permet d'attirer l'attention de l'utilisateur sur la structure du document, et donc de lui en faire prendre conscience. L'utilisateur aura donc moins tendance à faire du "bricolage". Pour le designer, la mise au point des css devient plus facile, et les "comportements du site" lors d'évolutions futures sont plus prévisibles.
En outre, par son approche, WYM editor a la possibilité de rester très simple au niveau conceptuel:
Tout ce que fait WYM editor, c'est travailler avec des balises simples (h1, h2, h3, p, ul, li, ...) sans prise de tête comme on peut le voir dans d'autres éditeurs, où on peut régler des tonnes d'attributs (couleur de fond, alignement, etc.), lesquels se trouvent mélangés au code.
Avec WYM editor, il suffit simplement d'assigner aux éléments des classes que le graphiste aura prédéfinies. Le graphiste peut aussi créer des restrictions: telle classe s'appliquera seulement aux élément "p", telle autre classe seulement aux "ul". De nouveau on empêche l'utilisateur final de faire n'importe quoi, tout en lui facilitant l'édition. Dans le cas d'un client, celui-ci aura moins d'appréhensions à confier les mises à jour à un de ses employés.
Grâce à la conformité stricte XHTML, ce qui sort de WYM editor (et avec un coup de main de tidy) est du XML bien propre, ce qui veut dire, comme l'a dit jf_h, que les traîtements XSLT sont possibles. L'intérêt de la chose ne saute peut-être pas aux yeux, voici exemple parlant:
Nous avons été confrontés au problème d'un site où il fallait absolument des images avec légendes. Pour cela on peut utiliser une liste de définition, ce qui nous donne par exemple:
<dl>
<dt>(image)</dt>
<dd>(légende)</dd>
</dl>
Sémantiquement c'est bon, et avec un petit coup de css on affiche ça comme on veut... Oui mais pour que ça ait de l'intérêt, il faut que l'utilisateur final puisse faire ça lui-même dans l'éditeur. Et c'est là que se trouve le problème: il s'agit d'une construction très difficile à implémenter dans un éditeur, et même si vous y arrivez, vous risquez d'embrouiller la personne qui devra s'en servir.
Grâce au fait que le code est transformable par XSLT, il suffit que l'utilisateur insère son image, et indique une description (attribut title), ce qui reste très simple et basique.
Lorsque la page est publiée, notre CMS lui applique une transformation XSLT, qui va permettre de remplacer les éléments
<img src="foo.jpg" alt="bar" title="légende de l'image" />
par:
<dl>
<dt><img src="foo.jpg" alt="bar" title="légende de l'image" /></dt>
<dd>légende de l'image</dd>
</dl>
On peut facilement étendre ce principe pour résoudre toutes sortes de problèmes:
Pour reprendre un nouvel exemple, créer un tableau dont les lignes ont une couleur alternée devient pour l'utilisateur aussi simple que de créer un tableau puis de lui assigner une classe prédéfinie... Le reste se passe en coulisses, puisque la page finale peut être manipulée à volonté avec des XSLT.
En conclusion, je dirais que grâce à cette approche dans l'utilisation des standards web, WYM editor propose une grande souplesse tout en étant moins compliqué que les éditeurs WYSIWYG habituels.