Jeudi 8 décembre 2005 — Dernier ajout samedi 15 décembre 2007

Un éditeur WYSIWYG pour SPIP ?

Les raccourcis typographiques de SPIP sont un outil fantastique. Mais leur maîtrise n’est pas tout à fait aussi simple que celle de la mise en forme du texte dans n’importe quel traitement de texte.

Le besoin de disposer d’un éditeur de texte WYSIWYG permettant de travailler en mode pré-visualisation immédiate revient donc régulièrement dans la communauté (il suffit pour s’en convaincre de chercher sur spip-contrib : WYSIWYG et autres FCKEditor).

MàJ du 15 mai 2006 : Clerver-Age dans sa lettre d’information de ce jour conforte l’idée maitresse de cet article : il faut mettre en sens et non mettre en forme.

MàJ du 15 décembre 2007 : voir aussi la suite de cette réflexion sur Contrib

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
  • PDF
  • 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 :

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

Schéma de l'éditeur WYSIWYG de SPIP

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 ?

Finalement, ce n’est pas si simple à mettre en œuvre.

Mais Cédric et Christian ont commencé le travail sur la Zone :

  • Dojo (sera probablement abandonné car ne gère pas les tableaux)
  • TinyMCE

[1Les standards W3C étant un outil au service de l’accessibilité d’un site, pas un but en soi.

[2Idéalement, une version light de l’éditeur pourrait exister pour les champs qui ne passent qu’à travers typo().

Vos réactions

  • Nicolas 4 décembre 2006 09:54

    Pourquoi ne pas créer un Overlay pour le BBComposer qui permettrait de proposer un language supplémentaire (en l’occurence, Spip et tous ses raccourcis propres).

    Ca rejoint l’idée de sémantique (le bbcomposer est un éditeur WYSIWYM) et aussi d’application client (limitation des transferts et pas d’HTML ajouté).

    • Un éditeur WYSIWYG pour SPIP ? 4 décembre 2006 13:43, par Pyrat.net

      J’ai regardé BBComposer avec intérêt.

      Mais

      • il est d’une part limité à FireFox (or SPIP a vocation à être utilisable quel que soit le navigateur).
      • Et d’autre part, BBComposer ne gère pas les raccourcis typographiques SPIP.

      Donc, pour l’instant, aucun intérêt à utiliser BBComposer avec SPIP.

  • Il n’ya pas que TinyMCE et Dojo 30 mai 2006 18:31, par Mehdi Cherifi

    Bonjour,

    j’avoue utiliser spip de manière assez régulière depuis maintenant 2 ans ! cet outil est formidable ! si si il y a besoin de le rappeler !

    personnelment actuellement j’ai mis en place une version personnelle de SPIP (un peu dans le genre de pyrat, mais tout en .php basé sur spip 1.8.3) laquelle inclus un éditeur wysiwyg, en l’occurence FCKeditor 2.3b (sortie tout récemment)

    Franchement il est super mais c’est juste que pour l’adapter à spip il faut toucher au code central !

    Je viens de découvir un nouveau venu sur la scène des éditeurs WysiWyg, il est assurémment open-source, rapide, compact et très peronnalisable !

    il s’agit de : openWYSIWYG - http://www.openwebware.com/products/openwysiwyg/

    supporte : Internet Explorer 5.5+, FireFox 1.0+, Mozilla 1.3+ & Netscape 7+

    l’ouverture de l’éditeur à de nouveaux raccourcis typographiques (il doit être aisément extensible) ben c’est son cas à celui-ci en plus la traduction vers diverses langues est simple : un seul fichier à traduire, pour le support du multilingisme il faudra attendre !!

    quelques soucis existent sur firefox 1.5 et ie 7b mais c’est en cours de correction.

    une version modifiée incluant l’upload d’image (en php) existe ! exemple de cette version modifiée : http://www.atwebresults.com/wysiwygdemo/example.html

    téléchargement de cette version modifiée : http://www.atwebresults.com/wysiwygdemo/WYSIWYG.zip

    je crois qu’il aura un bel avenir et la communauté spip devrait s’y intéressé d’un peu plus prêt !

    @+

  • 9 mai 2006 02:17

    Depuis 2004, j’ai fait bcp d’essais avec des éditeurs WYSIWIG en ligne sur SPIP. J’en suis à 4 : KTML, HTMLAREA, FCKeditor et, enfin, TinyMCE.

    Je viens d’ailleurs de laisser sur SPIP-Contrib une contribution pour l’utilisation de TinyMCE (qui manquait) avec la 1.8.3. Actuellement, je considère que TinyMCE est la bonne solution pour 3 raisons principales :

    • Ne nécessite pas de modification de fondamentale du noyau (très interessant pour les mise à jour de SPIP)
    • Soupplesse de mise en œuvre (possibilité de transformer en éditeur en ligne TOUS les champs TEXTAREA des TOUTES les pages de l’espace privé !)
    • Possibilités de « customisation » importantes

    Concernant le copier/coller à partir de Word, c’est une vrai malédiction quelque soit l’éditeur il est vrai. Mais il est possible de « brider » celà d’une manière ou d’une autre. TinyMCE, notamment, permet de copier/coller de Word sans garder les fameux styles propres à Word (mso.normal, etc.).

    Le principal problème reste encore la compatibilité avec les différents navigateurs. Là encore, TinyMCE est parmis les mieux placés même s’il faut les dernières versions pour Opera et Safari. Cette compatibilité va donc s’étendre dans le temps.

    Je ne veux pas critiquer les raccourcis typographiques car je considère qu’ils étaient nécessaires au début de SPIP mais il faut désormais avancer sinon SPIP va perdre de l’intérêt dans le temps. WordPress propose en standard TinyMCE comme éditeur pour ses pages. Avec sa technologie à base de plugins, XOOPS propose plusieurs éditeurs en ligne.

    Si SPIP aussi se met aux plugins, nous avons enfin la porte ouverte à ce genre d’avancée. Et ainsi rien ne devra empècher de choisir le type d’édition que l’on désire offrir aux rédacteurs de plus en plus exigents et habitués au WYSIWYG. Celà semble être le cas pour SPIP 1.9 qui devrait dors et déjà proposer des plugins TinyMCE et FCKeditor.

    C’est une bonne chose…

    • Salut,

      TinyMCE à l’air intéressant mais je ne trouve la contribution laissé sur SPIP-contrib.

      merci

    • Un éditeur WYSIWYG pour SPIP ? 20 octobre 2007 11:07, par Jacques

      Bonjour ,

      Je suis à la recherche d’un quelconque editeur wysiwyg permettant d’être intégré à SPIP. Pourquoi ? Bien que ayant vu que ce n’est pas la panacé pour la typo SPIP ;pour les instit et les élèves de mon école , c’est un rien plus facile pour créer leur article aussi si vous savez m’en indiquer un qui dispose aussi des instructions à suivre pour l’install,je serais vivement intéressé. J’ai parcouru votre site et celui de spip,FCK ne me plait pas vu quelques problèmes rencontrés.Tiny ou dojo ,pourquoi pas ? mais comment les installer , beaucoup se posent la question sans avoir de réponse. Si vous pouviez m’aiguiller pour un spip 1.9.2c et sarka 2.0.2 Cordialement , Jacques Chantraine

      • Un éditeur WYSIWYG pour SPIP ? 20 octobre 2007 11:18, par Jacques PYRAT

        Franchement, en l’état, il vaut mieux utiliser la Barre Typo V2 qui dispose d’un mode de prévisualisation immédiat et temps réel.

        Sinon, il y a plusieurs plugin FCKEditor pour SPIP. Mais franchement, vous perdrez au change.

        PS : ne sous-estimez pas les capacités des enfants à apprendre et à utiliser quelque chose de plus puissant que le WYSIWYG.

  • Un éditeur WYSIWYG LOCAL pour SPIP ? 19 janvier 2006 22:29, par Tiflopin

    Bonjour,

    Nous hésitons à installer un spip pour une asso qui est dans un village à bas débit pour encore un ou deux ans … Pensez-vous qu’il existe ou que des gens travaillent sur un éditeur WYSIWYG pour les rédacteurs (Et non les webmasters) en LOCAL. En fait, un backend en local qui permettrait d’avoir la puissance des certains éditeur libre tout en économisant les transferts.

    Ce serait au backend de spip l’équivalent du client mail au webmail.

    Un plugin pour NVU ou Quanta ?

    Merci

    • Un éditeur WYSIWYG LOCAL pour SPIP ? 7 février 2006 16:49, par philippe lara

      il existe SPIPEDIT qui peut répondre a vos besoins, mais personnellement il ne m’a pas convaincu

      • les reflexions devraient se poursuivre et se partager ici sur spikini

        • Un éditeur WYSIWYG LOCAL pour SPIP ? 2 mai 2006 10:50, par Jean-Luc

          Bonjour,

          Je suis un utilisateur « professionnel » potentiel. Je parle ici de production de doc par et à destination de professionnels en dev logiciels, essentiellement dans le but de fournir un site de référence en support aux développements. Je regarde diverses solutions, dont Spip.

          Et aujourd’hui, ma réflexion à propos de la partie privée serait plutôt d’offrir aux auteurs un nombre volontairement limité de modèles de documents, chacun ayant sa structure propre. Par ex. un doc de type FAQ est quelque chose qui ressemblerait à une brève mais avec des champs Question et Réponse, un white paper un doc complexe, peut-être conforme à la structure DocBook … etc … Tout ça, avec des noms de champs paramétrable en fonction des modèles. Il s’agit d’offrir à certains utilisateurs le moyen rapide et contrôlé d’enrichir une base de connaissance à partir de leur expérience. Mais ça doit être particulièrement simple parce qu’ils n’ont pas tant de temps que cela à y consacrer.

          Bref, quelque chose à l’opposé de l’éditeur Wysiwyg qui me semble être un non sens pour l’utilisation que je décris. Parce qu’il ne s’agit pas là de favoriser la créativité.