Je suis peut-être difficile — ou compliqué — mais je ne trouve pas l’éditeur idéal (vous me direz que « trouver un idéal » revient à se mettre le doigt dans l’oeil, mais bon…). Je parle des éditeurs plus ou moins WYSIWYG comme TinyMCE, FCKEditor, Xinha, htmlArea, Cross-Browser Rich Text Editor (RTE), Cross-Browser WYSIWYG Editor, etc. A noter que WordPress intègre par défaut une version modifiée de TinyMCE qui fonctionne désormais plutôt bien… lorsqu’on se limite à des structures de contenus assez simples.
Moi je rêve d’un éditeur WYSIWYG qui permettrait des imbrications de balises comme l’insertion de listes de définition à l’intérieur d’une liste ordonnée ou non-ordonnée, par exemple :
<ol> <li> <dl> <dt>Terme 1</dt> <dd>Définition 1</dd> <dt>Terme 2</dt> <dd>Définition 2</dd> </dl> </li> </ol>
Voire même qui permettrait de choisir les balises se trouvant à l’intérieur des éléments dd comme :
<ol> <li> <dl> <dt>Terme 1</dt> <dd><p>Définition 1</p></dd> <dt>Terme 2</dt> <dd><blockquotes>Définition 2</blockquotes></dd> </dl> </li> </ol>
La question n’est évidement pas de (re)lancer un débat sur l’intérêt de mettre en place une telle structure, mais plutôt de voir si un tel éditeur existe déjà (le web est si vaste, on ne sait jamais) ou s’il serait possible de créer un plugin pour les éditeurs existants, sur le modèle de l’éditeur de Scribefire qui permet de saisir la balise HTML de son choix en cliquant sur Custom HTML suite à une sélection de texte (ce qui n’est déjà pas si mal).
L’idéal serait évidemment de pouvoir proposer, suite à une sélection, une liste de balises en fonction de la sélection elle-même : type bloc ou en ligne, afin d’éviter les imbrications contre-nature 😉
Je rêve, ou bien ?
J’en connais pas d’autre que tu n’ai pas cité ! Par contre pour l’avoir bidouillé TinYMce permet de bien contrôler le contenu retourner la solution « parfaite » est pte là
Il me semble qu’autant FCKeditor que TinyMCE permettent de créer des plugins. En revanche, j’ignore comment cela fonctionne, et j’avoue avoir été plus d’une fois agacé de constater que l’éditeur de WordPress modifie mon code HTML à l’insu de mon plein gré…
@alchymi > yep, je pense aussi que la solution passe par là.
@Martin > En fait, je ne suis pas sûr que ce soit l’éditeur en lui-même qui modifie le code, mais plutôt certaines fonctions « filtre » que wordpress applique sur le contenu, comme le fait de « stripper » les balises p ou encore les attributs de certaines balises comme start= »x » pour la balise ol…
Pourquoi ne pas adopter la syntaxe Markdown ? Elle est simple à retenir, facile à mettre en place sous WordPress, et répond à pas mal de tes demandes.
http://michelf.com/projets/php-markdown/
@20cent > Merci bien pour le lien. En fait, pour mes besoins strictement personnels, l’éditeur intégré suffit, même si je trouve qu’il manque un menu déroulant avec l’ensemble des balises 😉
Mais dans l’optique où l’on livre un site clé en main, il me semble peu jouable de demander aux clients d’apprendre une syntaxe spécifique, fut-elle très simple en apparence 😉
Markdown a l’air intéressant mais d’après ce que j’en ai vu, ça reprent grosso modo la syntaxe que l’on trouve dans la plupart des wiki, à moins que quelque chose d’important m’ait échappé.
Tu auras du mal aussi à éduquer ton client à produire un code sémantiquement correct de toute manière non ?
Ce que j’ai aimé pour ma part dans Markdown, c’est avant tout la simplicité d’approche et la qualité du code produit.
Après, pourquoi ne pas le coupler à un petit script fait maison ou à des outils tels que markItUp! (http://markitup.jaysalvat.com/examples/markdown/) ?
Mais oui en effet, il s’agit d’un clone de la syntaxe Wiki. Un clone avec une approche intéressante…
J’ai moi meme testé beaucoup de WYSIWYG et aucun ne m’a totalement satisfait!
La source du problème n’étant pas le WYSIWYG en lui meme mais plutot l’utilisation que peut en faire un utilisateur ‘lambda’.
Alors dans mon prochain projet je vais essayer un WYSIWYM (What You See Is What You Mean), et plus précisément WYMeditor (http://www.wymeditor.org/en/). On verra le résultat ;o)
@20cent > « Tu auras du mal aussi à éduquer ton client à produire un code sémantiquement correct de toute manière non ? »
et oui, le fond du problème est bien là 😉 et il faut beaucoup insister pour faire respecter les bases disponibles dans l’éditeur intégré de WP : rien que la hiérarchie des titres qui doit commencer à h3 lors de la rédaction d’un billet a du mal à passer.
Mais bon, il ne faut pas jeter la pierre aux utilisateurs néophytes, même si parfois, c’est rageant de constater qu’ils déploient des trésors d’ingéniosité pour aboutir à une mise en forme que l’on a prévu pour être accessible en un clic 😉
Je me pencherais donc plus avant sur Markdown même si la mise en garde :
If your old entries are written in HTML (as opposed to another formatting syntax, like Textile), they’ll probably stay fine after installing Markdown
fait un peu froid dans le dos lorsqu’on n’en est pas à son premier billet ^^
@Denis > je viens de télécharger WYMeditor, je vais voir s’il peut faire l’affaire. Merci pour le lien 😉
Outre l’écriture de plugins, qui permet d’ajouter des fonctionnalités diverses, FCKEditor permet de définir des modèles – pratique pour les néophytes. Je ne parle même pas de faire apparaître certaines classes CSS via un fichier XML dans le menu déroulant. Pour moi il est un des éditeurs les plus complets.
Bonjour,
Voici mon vote:
Pour un site à fort contenu rédactionnel, maintenu par un ou plusieurs rédacteurs professionnels, Markdown est un très bon choix. C’est une syntaxe textuelle (à l’instar des syntaxes wiki) assez claire, qui est plutôt intuitive car elle utilise des conventions de «typographie ASCII» assez connues (mais surtout par les anglo-saxons, à vrai dire). Son mérite principal est d’être une syntaxe aux capacités limitées, et d’accepter le code HTML inline ou encore des blocs de code HTML. Si on veut écrire un tableau de données en tenant compte des règles d’accessibilité, on pourra le faire directement en HTML, ce qui sera plus efficace que ce que proposent certaines syntaxes textuelles un peu usines à gaz (essayez de mettre un tableau de données sur Wikipédia, pour voir… ;)).
Le HTML brut, avec gestion automatique des paragraphes et BR, est aussi envisageable.
Pour un utilisateur non expert, WYMeditor me semble très prometteur. Je n’ai pas encore eu l’occasion de le tester correctement, par contre. Si quelqu’un a utilisé cet éditeur sur un site géré par un client, je serais curieux de savoir ce que cela donne.
Viennent ensuite TinyMCE et FCKeditor, qui me semblent assez proche. TinyMCE semble avoir les faveurs des dernières versions des principaux CMS, bien qu’il n’ait de «tiny» que le nom. 😀
Ces éditeurs jouent bien leur rôle pour faire des suites de paragraphes avec des liens et du texte en gras dedans. Éventuellement des titres. Pour le reste c’est un peu la merde, que ça soit pour des raisons techniques ou parce que les fonctionnalités avancées ne seront de toutes façons pas utilisées, ou alors utilisées par un rédacteur non technicien qui n’y comprendra rien et n’arrivera pas au résultat voulu.
Une réflexion en passant: s’il faut souvent passer derrière un client pour corriger ses saisies, ce n’est pas que la faute des outils qui seraient trop limités, pas assez ergonomiques, ou encore bugués. C’est aussi et surtout parce que ce n’est pas le rôle du client ou du rédacteur non technicien que de produire des épreuves ne nécessitant pas de corrections. Le principe même de fournir un outil de publication sans contrôle final à un rédacteur est bancal. Demandez aux professionnels de l’édition (presse, magazine, livre). Nous sommes en train de découvrir que l’édition web n’est pas si différente de l’édition tout court.
Dans le cadre d’un site web, nous avons deux solutions:
1. soit laisser le rédacteur non technicien publier des contenus sans contrôle, et limiter les dégâts avec un choix d’outil correct — éventuellement en bridant les outils pour limiter les erreurs possibles — et un peu de formation;
2. soit mettre en place une chaine de validation dans laquelle chaque article serait corrigé avant sa publication.
(Je parle ici uniquement de correction technique et pas de validation des contenus.)
Dans le premier cas, on aura des contenus posant un problème de qualité (accessibilité déficiente, typographie erronée, balisage raté ou trop chargé ou sous-exploité, mauvaise utilisation des styles pré-établis, etc.). Ce problème ne sera pas très important, mais il compte malgré tout. Un livre à la maquette claire mais au contenu de travers ne sera pas très agréable à lire, et ne donnera pas une impression de professionnalisme.
Dans le deuxième cas, pourvu que la chaine de validation soit respectée et que l’intervenant en bout de chaine soit compétent, on évite cet écueil. Mais on rajoute un cout à la publication.
@Florent V. > J’essaie WYMeditor, mais pour l’instant rien ne marche (je vais relire la doc qui m’avait paru pourtant bien simple…) ; La syntaxe Markdown semble également intéressante et je me demande si je ne vais pas l’utiliser pour rédiger mes billets puisque ce système semble correspondre aux imbrications de balises auxquelles je fais allusion dans ce billet — à part les listes de définitions qui semblent absentes… (mais on peut mélanger du html à la syntaxe, donc ce n’est pas un problème bloquant).
En revanche, je ne partage pas totalement ton point de vue quand tu dis que :
Les outils comme TinyMCE ou FCKEditor sont conçus pour être utilisés par toute personne sachant manier un traitement de texte comme Word ou OOo… Et à priori je ne vois pas pourquoi un client en saurait moins que l’utilisateur français moyen sur ces outils 😉
Certes, mais comme partout, les cycles de production se plus court, et la production d’information n’y échappe pas. Quand j’étais étudiant en information et documentation (il y a env. 18 ans), il y avait déjà des chefs d’entreprises d’une cinquantaine d’années qui prenaient des cours de dactylo pour être plus autonomes. Je ne peut pas croire qu’il reste encore des gens pour qui la notion de titres et de sous-titres soit totalement étrangère.
Je persiste et signe sur le «ce n’est pas le rôle du client ou du rédacteur non technicien que de produire des épreuves ne nécessitant pas de corrections.» Si le client ou rédacteur non technicien veut se former sur la technique (comme le chef d’entreprise quinqua qui apprend la dactylo), apprendre à utiliser correctement un TinyMCE ou une syntaxe Markdown en y passant du temps, pourquoi pas. Mais gare au mythe du «c’est comme dans Word, donc on peut obtenir un résultat de qualité sans être formé».
… mythe que tu revisites avec entrain. Je te cite: «Les outils comme TinyMCE ou FCKEditor sont conçus pour être utilisés par toute personne sachant manier un traitement de texte comme Word ou OOo…»
Le problème, c’est que les personnes qui savent manier un traitement de texte sont excessivement rares! Tout le monde bidouille du Word (ou du OpenOffice Writer), mais qui utilise des modèles de documents et des styles prédéfinis?
(Pour la petite histoire, j’ai commencé mon apprentissage de la séparation contenu–mise en forme avec des cours sur la technique des styles dans Word, en fac de lettres.)
Je ne prône aucune prise de contrôle des techniciens sur la publication de contenus, mais force est de constater que si on veut assurer la qualité technique d’un contenu web il ne suffit pas d’un FCKeditor bien paramétré. D’où ma réflexion.
Ensuite, il est vrai que certains contenus ne demandent qu’une intervention minime car ils sont peu complexes: utilisation d’un ou deux niveaux de titres, de deux ou trois styles prédéfinis, de liens et de texte en gras, et basta. Je trouve WYMeditor pas mal pour ça (boite de styles prédéfinis à droite de la zone d’édition). Pour tester, il y a http://demo.wymeditor.org/demo.html
Deux dernières choses:
* si tu n’as jamais testé XStandard, ça vaut le détour;
* le nerf de la guerre, c’est l’intégration au CMS utilisé, et notamment à son gestionnaire d’images ou plus généralement de médias.