Quelques mésaventures avec le WYSIWYG

Cet article est reposté depuis une source devenue inaccessible.

Comme vous avez pu le voir, nous avons fait évoluer l'éditeur de texte de l'administration d'Overblog. Il utilise dorénavant l'éditeur WYSIWYG CKEditor. Pour garder la philosophie WYSIWYM, nous avons du produire un convertisseur de HTML en WikiDOM. En pratique, ça nous donne un éditeur bien plus confortable, plus rapide, plus fluide, qui gère la correction automatique native et qui sera plus facile à faire évoluer. Mais en contrepartie… je me suis condamné à un debug de l'éditeur jusqu'à la fin de mes jours… Quelques exemples qui me font détester les éditeurs WYSIWYG sur le web à travers les premiers bugs fixés.

Bug n°1 : copier coller

Pendant mes développements, j'avais bien pensé à coller du texte copié depuis une page web. Mais pas depuis un éditeur texte tout con. Et ça m'aurait permis de constater un bug qui non seulement empêche de coller ce texte, mais en plus casse l'éditeur. Après quelques recherches, on apprends que ça a été corrigé il y a 3 ans dans CKEditor 3 mais que le bug est revenu dans la version 4. Il est dit qu'il est corrigé, mais le passage à la version 4.0.1.1 ne résous pas le problème complètement. Donc on doit ajouter le workaround suivant : on écoute l'évènement paste de l'éditeur et on regarde la valeur qui est en train d'être collée. S'il s'agit de divs avec la classe cke_pastebin, alors nous enlevons les div, remplaçons les /div par des br et plaçons le tout dans un p avant de laisser la main à l'éditeur qui a ainsi une valeur propre à coller.

Bug n°2 : espaces insécables

Alors celui là, il a failli me rendre chauve. Plaçons le contexte. Quand on tape du texte dans CKEditor, c'est du HTML qui est produit. Du HTML sur lequel nous avons très peu de contrôle et qui peut facilement se transformer en soupe de tag. Grâce à notre convertisseur vers WikiDOM, à la perte de focus de l'éditeur, nous transformons le HTML produit en WikiDOM, ce qui permet de ne garder que le contenu sémantique de l'éditeur. Nous stockons ce WikiDOM pour sauvegarde en base. Puis, nous retransformons en HTML pour regénérer un HTML propre que nous envoyons dans l'éditeur si changement il y a eu.

Voilà ce que ça donne en pratique :

D'un habile ⌘+A, je sélectionne l'ensemble de la page où je me trouve : l'admin Overblog

Je colle dans l'éditeur, on a donc une admin dans l'admin. On pourrait aller plus loin, mais les limbes sont dangereuses.

Je clique hors de l'éditeur, son contenu est transformé en quelque chose de bien plus simple : du texte.

Tout semblait bien se passer jusqu'à ce qu'on me remonte le second bug chiant : les espaces et les retours chariots ne sont pas gardés quand ils sont dans un block de type pre (la balise HTML pre, qui sert à afficher du texte formaté). Allons voir ça de plus près.

Sachons que :

Dans le WikiDOM, on supprime les groupes d'espaces. Tout simplement parce que c'est le comportement normal d'un parser HTML : une suite de caractères blancs (espace, tab, retours charriots) sont affichés en tant qu'un unique espace, donc on s'abstient de garder des caractères qui ne servent à rien.
On supprime les retours charriots (\n) puisque le parser HTML les considère comme un caractère blanc, mais on transforme les br en retour chariot (dans le WikiDOM).
On transforme les espaces insécables (& nbsp;) en espaces simples.

Pourquoi ne pas garder les espaces insécables ? C'est la faute à l'éditeur : il en fout partout (enfin presque partout puisque c'est le cœur de notre bug comme on le verra à la fin). Un éditeur WYSIWYG c'est du web, ça fonctionne donc de la même façon. Et si un utilisateur a la mauvaise idée de taper plusieurs fois sur espace, si l'éditeur se contentait de mettre des espaces normaux, l'utilisateur ne verrait rien puisqu'un seul espace serait affiché. Pour remédier à ça, dès le second espace, un & nbsp; est saisi. Ainsi, à l'affichage, on voit bien plusieurs espaces se suivre. Mais comme on veut du WYSIWYM, on ne veut pas de ces espaces utilisés pour faire de la mise en page. Alors on les enlève.

Le malheur est dans le pre

Mais dans un block de type pre, on a envie de garder les espaces. Pour afficher du code source indenté par exemple. De toute façon, c'est le principe de ce block : il affiche des caractères blancs qui sont normalement ignorés : espaces, tabulations et retours charriots. Alors on modifie le convertisseur WikiDOM pour qu'il autorise le caractère espace insécable s'il se trouve à l'intérieur d'un tag pre. Mais ça ne change rien. Alors on fouille, on bidouille, on s'arrache quelques cheveux. Puis on comprends.

Comme expliqué plus haut, dans un paragraphe, l'éditeur est obligé d'insérer des & nbsp;. Mais dans un pre, ce n'est pas la peine, car le navigateur sait afficher plusieurs simples espaces contiguës.

Alors on se retrouve à :

Transformer les espaces en espaces insécables quand on est dans une balise pre,
Transformer les espaces insécables en espaces quand on est ailleurs.

Damned

Et le plus rigolo, c'est qu'en même temps que je fixe ces bugs, j'en trouve d'autre. Des détails comparé à ces deux là, mais si j'en trouve d'autres bien pourris, je rédigerais un nouvel article. J'ai été condamné au debug perpétuel par le simple fait d"avoir choisi un éditeur WYSIWYG. Malheur à moi !