Salut,
je me demande comment l'intégration de l'éditeur wysihtml5 dans SPIP3 serait possible et si c'est un bon choix.
Démonstration
http://xing.github.com/wysihtml5/
Comment intégrer wysihtml5 ds votre site web
https://github.com/xing/wysihtml5/wiki/Getting-Started
Vous avez une idée comment faire (si c'est raisonnable) ?
merci, klaus++
On Thu, 24 May 2012 04:36:55 +0200, klaus++:
je me demande comment l'intégration de l'éditeur wysihtml5 dans SPIP3
serait possible et si c'est un bon choix.
Ça a l'air sympa.
Dans l'espace privé et dans les crayons ça serait sûrement possible,
car le textarea on l'a déjà, donc c'est un javascript à ajouter et le
bout de HTML pour la barre d'outils. Via un plugin ça a l'air faisable,
à première vue (et un ou des modèles pour la barre d'outils).
Par contre c'est une interface javascript qui produit du HTML dans
le textarea, c'est donc ce HTML que le formulaire va envoyer. Ça ne
produit pas du code SPIP. Du coup j'imagine que les bonnes idées sont à
avoir de ce côté-là.
Idées en vrac :
- se résigner à stocker du HTML en base, et pas du code SPIP.
- reprendre des bouts du code pour produire des raccourcis SPIP.
- faire intervenir textwheel quelque part dans le traitement...
L'idée de textwheel est de permettre une souplesse sur les formats
utilisés (syntaxe SPIP, markdown, HTML, etc.), donc ça pourrait être un
bon allié.
Merci !
On Thu, 24 May 2012 04:36:55 +0200, klaus++:
je me demande comment l'intégration de l'éditeur wysihtml5 dans SPIP3
serait possible et si c'est un bon choix.Ça a l'air sympa.
...
Idées en vrac :
- se résigner à stocker du HTML en base, et pas du code SPIP.
inconvénients :
avantages :
- reprendre des bouts du code pour produire des raccourcis SPIP.
ça c’est la fonction sale(), qu’il faudrait un jour nettoyer (si je puis dire).
- faire intervenir textwheel quelque part dans le traitement…
L’idée de textwheel est de permettre une souplesse sur les formats
utilisés (syntaxe SPIP, markdown, HTML, etc.), donc ça pourrait être un
bon allié.
Hélas de ce côté il n’y a rien eu de fait
– Fil
* Fil tapuscrivait, le 24/05/2012 08:54:
Idées en vrac :
- se résigner à stocker du HTML en base, et pas du code SPIP.inconvénients :
- pas de raccourci genre<docX>
- présence de codes et classes dans le "texte" qui salissent le moteur de
recherche
Il faudrait regarder du côté du plugin CKEditor pour SPIP : CKeditor 3.x et 4.x - SPIP-Contrib
qui est capable de stocker au format raccourcis typo de SPIP et gère les docX
Merci pour vos commentaires et pour le lien vers CKeditor-3-0.
J'ai été attiré par la possibilité de produire du HTML 5 propre en mode WYSIWYG et par la facilité d'installation. Pourquoi ?
En principe SPIP et ses squelettes gèrent très bien le HTML 5 mais ses raccourcis posent un problème sérieux aux rédacteurs qui ne codent pas habituellement en HTML. Ceux-là produisent de mauvaises imbrications de balises HTML. Avec la souris ils marquent une citation qui commence dans un praragraphe et s'étend sur le suivant (ou pire encore sur plusieurs paragraphes), ils cliquent sur "mettre en italiques" et fabriquent du code du genre:
<p>texte<i>Début de citation.</p><p>Paragraphe suivant</i>et fin.</p>
Il faudrait regarder du côté du plugin CKEditor pour SPIP :
CKeditor 3.x et 4.x - SPIP-Contrib
qui est capable de stocker au format raccourcis typo de SPIP et gère les
docX
Si CKeditor-3-0 leur permet de faire n'importe quoi comme ils font
d'habitude dans Word et de produire du code SPIP qui lui permet à SPIP
de produire du HTML 5 valide, c'est parfait, je cours tout de suite installer
CKeditor-3-0. Sinon je reste au niveau le plus simple possible en leur
disant, d'utiliser <cadre></cadre> pour marquer des citations longues.
klaus++
Dans ma TODO list il y a de fabriquer un plugin de validation de la
conformité sémantique du texte écrit par les rédacteurs (qui c'est
vrai s'embrouillent avec les raccourcis, les puces, etc.), avec un
feedback sous forme d’icônes dans la partie publique (connecté) et
privée.
C'est peut-être aussi une piste différente du WYSIWYG/M que je trouve
intéressante.
Mais hélas, ce n'est pas très haut dans ma TODO donc il faut compter
quelques mois (sans compter les migrations vers SPIP 3)...
Mon expérience des wysiwyg est que parfois, (et parfois très souvent selon la qualité des éditeurs), le générateur “se perd”, c’est à dire, plus capable de mettre en gras notre sélection, ou plus capable d’enlever un style. (Parce que le code généré n’est pas conforme à un moment donné…) Du coup, obliger de passer par le source. Et l’utilisateur final n’est pas toujours capable de s’en sortir. De plus, ça l’oblige à connaitre 2 façons de faire.
D’autre part, cela permet à l’utilisateur final de réaliser des articles complétement hors charte graphique en utilisant toutes les couleurs de l’arc en ciel, dans le cas ou l’éditeur propose des couleurs de fond et de texte…
Dans le cas d’un wysiwyg, il faut donc qqch de fiable à 100%. Sinon, ce serait une régression de SPIP.
Stocker du HTML en base ?
S’il s’agit de XHTML strict et qu’on est capable de le re-transformer en Syntaxe SPIP ou BBCODE ou XML ou etc. pourquoi pas…
Sinon, c’est qu’on aura stocké un mélange de fond et de forme et ça, ce serait vraiment une régression. Avec des difficultés de réaliser une nouvelle mise en forme d’un site…
Sur un CMS, la qualité de l’éditeur et des données produites est qqch de primordial. Car c’est qqch qui est utilisé par des novices au quotidien.
Personnellement, je préfère de loin avoir un éditeur de syntaxe SPIP de base comme aujourd’hui, qu’un editeur wysiwyg qui ne respecterait pas les principes de fiabilité et de séparation fond/forme.
Cela semble être le cas de l’éditeur proposé… 
Autre éditeur qui avait circulé sur la liste :
http://www.mail-archive.com/spip@rezo.net/msg42826.html
Et il me semble que j’avais vu passé un éditeur “reflexif” aussi avec d’un côté le wysiwyg, et de l’autre une syntaxe textuelle, l’édition pouvant être faite des 2 côtés. J’ai oublié son nom ! si je le retrouve, je transmettrais.
Julien
Oui oui, j'acquiesce. Pourtant on me dit "dans Word c'est possible" et "en tant qu'utilisateur je n'ai pas à me soucier de vos histoires d'imbrication".
C'est le genre de chose qui fait qu tu vends moins bien ton truc si tu es honnête et expliques aux gens qu'il faut un minimum de culture numérique pour maîtriser le web.
k++
Oui, je suis d’accord avec ça.
L’utilisateur final veut rédiger qqch sans se soucier de ce genre de problématique qui souvent le dépasse.
D’où l’importance du choix d’un éditeur qui s’occupe efficacement et intelligemment de séparer fond/forme et que l’administrateur pourra éventuellement paramétrer pour ne pas lui laisser trop d’options (comme les couleurs par exemple).
Julien