Pourquoi ce besoin n’a pas été intégré à SPIP ?
La réponse est très simple : SPIP permet de séparer le contenu de sa présentation au moyen des raccourcis typographiques qui vont préciser le sens du texte qu’ils encadrent.
En passant en mode WYSIWYG, on augmente le risque de voir les utilisateurs privilégier la présentation par rapport au sens. De plus, si jamais le texte vient d’un copier/coller depuis Microsoft® Word™, vous pouvez abandonner tout espoir de respecter les standards du W3C [1].
Enfin, SPIP permet de gérer du texte qui n’est pas forcément destiné à l’affichage sur une page web, mais aussi :
- calendrier au format iCal
- Flux de syndication RSS
- WAP
- …
Que faudrait-il faire alors ?
Un éditeur WYSIWYG qui permettrait en fin de compte de continuer d’enregistrer des raccourcis typographiques SPIP serait la seule solution viable.
Il faudrait de plus que cette solution fonctionne sur :
- Internet Explorer (Windows)
- FireFox (Windows, Linux, Mac OS X)
- Safari (Mac OS X)
Deux éditeurs WYSIWYG fonctionnent sous ces 3 navigateurs :
- TinyMCE
- Dojo Editor : peut-être le mieux pensé du moment !
MàJ du 15 décembre 2007 : SPIP a évolué, il intègre désormais jquery, et WYM Editor propose un moyen d’éditer le sens d’un texte en WYSIWYM…
Il faudrait de plus que cet éditeur soit utilisable de manière facultative.
Il devrait être disponible sur tous les champs de SPIP passant par la fonction propre() [2].
Principes de fonctionnement
Il est possible que le mode WYSIWYG ne soit pas complètement WYG, en particulier :
- Pour les images et documents : il faudra continuer à utiliser les mécanismes actuels de SPIP pour la gestion des documents et trouver un moyen d’indiquer que l’on est en train de mettre :
-
<imgNNN|alignement>: une image non réduite avec son titre en bulle d’aide -
<docNNN|alignement>:- une image avec son titre en dessous
- une image insérée en tant que document, réduite avec son titre en dessous, cliquable pour obtenir la version originale
- l’icone d’un document avec son titre en dessous
-
<embNNN|alignement>: un document multimédia (son, vidéo…)
-
- Pour les notes de bas de page : sans doute à faire apparaître dans une typo différente à l’intérieur du texte
- Les raccourcis spéciaux :
<quote> <code> <poesie> <cadre> <HTML> - Les liens interne, en particulier
[->12]qui affiche le titre de l’article 12 et fait un lien vers celui-ci. - …
Challenge
Les difficultés résident dans :
- la représentation quasi WYSIWYG des raccourcis typographiques de SPIP
- la réalisation d’une fonction typo_bis() et propre_bis() générant le HTML de la représentation WYSIWYG
- la conception de la fonction inverse transformant le HTML de l’éditeur WYSIWYG en code typographique SPIP
- l’ouverture de l’éditeur à de nouveaux raccourcis typographiques (il doit être aisément extensible)
Questions ouvertes
- Que doit faire l’éditeur au moment de l’enregistrement s’il reste du HTML non directement traduisible :
- le supprimer ?
- le laisser tel quel (c’est permis par SPIP) ?
- l’entourer de
<HTML> </HTML>?
- Que doit faire l’éditeur d’un code HTML copier/coller (de Word par (mauvais) exemple) ?
- L’éditeur doit-il transformer les entités HTML en leur équivalent caractère ?
- Doit-il fonctionner avec des langues à caractères non européens ?
- ?
Multilinguisme
MàJ du 10 mai 2006 : j’ai réalisé dernièrement que la question du multilinguisme avait été complètement oubliée dans la réflexion. Autrement dit, comment traiter les bloc <multi> ? Peut-être que l’éditeur dispose d’un onglet par langue du <multi> et donne la possibilité de rajouter des onglets à la demande ?
