CSS & Webdesign » TinyMCE

11 éditeurs HTML WYSIWYG et WYSIWYM

Bruno Bichet — Tue, 13 Mar 2012 12:54:01 +0000

Ces éditeurs WYSIWYG ont la particularité d’utiliser Javascript pour convertir le contenu des champs créés à l’aide de la balise textarea en contenu HTML principalement ; certains éditeurs proposent également d’autres syntaxes : Wiki, BBCodes, XBBCodes, Markdown, Textile ou Dotclear. Le point commun de ces outils est de proposer des icônes plus ou moins explicites pour donner aux portions de textes adéquates le sens ou la mise en forme désirés sans être obligé de saisir les balises HTML. Ces éditeurs sont généralement utilisés dans les CMS où ils permettent aux utilisateurs de saisir du texte presque comme dans LibreOffice ou Microsoft Word !

BBComposer — Cet éditeur se distingue des autres, car il se présente sous la forme d’une extension Firefox qui propose un environnement WYSIWYG pour produire du code HTML (mais aussi du Wiki, BBCodes et XBBCodes). Point fort : la création de super blocs pour envelopper du contenu avec des balises DIV et l’application de classes CSS sur les éléments. Revue complète dans BBComposer — l’éditeur HTML à consommer sur place ou à emporter. Démo.
TinyMCE — Editeur HTML simple à insérer dans votre CMS préféré. Il s’agit probablement de la solution la plus complète et la plus aboutie graphiquement — malgré le manque de la gestion des images et de l’upload dans la version gratuite. Il reste néanmoins possible d’acheter les modules correspondants. Démos.
CKEditor — L’accessibilité et la compatibilité avec les navigateurs et la possibilité d’uploader des images sur le serveurs sont les points forts de cet éditeur. Le code est valide et il est possible d’ajouter un container DIV en spécifiant une classe CSS (idem sur les liens, les images et d’autres éléments HTML). Très complet et joli graphiquement, c’est un concurrent sérieux à TinyMCE. Possibilité d’afficher les blocs HTML et d’utiliser des modèles pour vos articles. Démos.
Aloha Editor — Basé sur la propriété contenteditable de HTML5, Aloha présente une particularité intéressante : la barre d’outil flotte au-dessus du texte à modifier pour offrir une expérience immersive à l’instar du mode plein écran que l’on trouve dans WordPress. A propos de WordPress, voici une démonstration assez bluffante de la modification de contenu « sur place ». Point fort : produit du code xHTML5 valide ! Voir les autres Démos.
markItUp! — Ce n’est pas à proprement parler un éditeur WYSIWYG mais plutôt WYSIWYM. Il vous permettra de produire plusieurs syntaxes : HTML, BBCode, Markdown, Textile, Wiki ou Dotclear très facilement. Nécessite jQuery. Le point fort de markItUp est sa compatibilité avec des éléments extérieurs comme Farbastic, Simplemodal ou jQuery UI. Lire le tutoriel très complet de Clément Guillemain. Démos.
WYMEditor — Cet éditeur WYSIWYM (What You See Is What You Mean) met le paquet sur la sémantique tout en offrant un confort digne d’un éditeur WYSIWYG. Le point fort de cet éditeur est de fonctionner par classes CSS pour styler les différents éléments de votre contenu. Démos.
YUI Rich Text Editor — L’éditeur de Yahoo! Son architecture modulaire offre une extensibilité très importante avec des modules comme la recherche d’images sur Flickr, Calendrier pour afficher des dates ou l’insertion d’icônes. Point fort : peut être intégré de pratiquement n’importe quelle manière dans vos projets. Démos.
Xinha — Projet Open source sous licence BSD. Cet éditeur est hautement configurable et se nom se prononce comme Xena, la guerrière… Que demander de plus ? Démos.
jWYSIWYG — Basé sur jQuery, il offre de nombreuses options de configuration. Démos.
PHP Markdown — Lire Markdown — L’éditeur presque WYSIWYG.
htmlArea — Le projet est arrêté, mais il est toujours possible de télécharger la dernière version de l’éditeur. Le site est désormais un répertoire d’éditeurs WYSIWYG et d’autres outils web. A garder sous le coude.

N’hésitez pas à me faire part de vos retours d’expériences sur ces éditeurs HTML ou à proposer ceux que vous utilisez s’ils étaient absents de cette liste o/

Articles sur le même sujet

Créer des « Call to Action » ou des « boutons CSS » dans l'éditeur WYSIWYG TinyMCE

Bruno Bichet — Tue, 10 May 2011 11:46:46 +0000

Cette petite astuce toute simple permettra à vos clients⁽¹⁾ de styler certains liens différemment des autres (Call to action, bouton, etc.) depuis TinyMCE, l’éditeur WYSIWYG de WordPress. Il suffit de créer un lien et de le mettre en «gras» avec l’icône B. Cette combinaison toute simple vous donnera le composé HTML suivant :


    
        lien de téléchargement

Pour les styles CSS :

strong a {
    font-weight: normal;
    padding: 0.25em 0.5em;
    background: #F29F05;
    color: #000;
    -webkit-border-top-left-radius: 8px;
    -webkit-border-bottom-right-radius: 8px;
    -moz-border-radius-topleft: 8px;
    -moz-border-radius-bottomright: 8px;
    border-top-left-radius: 8px;
    border-bottom-right-radius: 8px;
}

On peut aller plus loin en isolant ce marquage HTML dans son propre paragraphe pour augmenter les possibilités. Comme dit le proverbe bien connu : «Plus il y a de marquage HTML et plus il y a de marrage sous les bretelles», comme le centrage, des backgrounds différents, etc.

Dans le même esprit, on peut également envisager de combiner un lien avec «l’italique» (I) pour styler ensuite le sélecteur em a.

D’un point de vue sémantique, l’importance des textes véhiculée par strong ou em devrait s’accorder avec une mise en évidence plus ou moins forte des contenus associés.

⁽¹⁾ Si c’est pour pour vos clients, ça devrait être bon pour vous aussi !

Articles sur le même sujet

Pour réparer éditeur visuel bloqué, casses un flux RSS ^_^

Bruno Bichet — Tue, 10 Jun 2008 10:01:00 +0000

Dans WordPress, le bloquage de l’éditeur visuel basé sur tinyMCE en position HTML arrive relativement souvent sans que l’on sache vraiment pourquoi. C’est typiquement le genre de petit soucis qu’on laisse passer un temps avant de s’attaquer au problème. En ce qui me concerne, j’ai parcouru les quelques ressources qui en parlait, pour découvrir que certains thèmes WordPress causaient des problèmes en ajoutant des fonctionnalités à l’éditeur.

Toutefois, dans mon cas, vu que mon thème, c’est moi qui l’ai fait, je sais ce qu’il y a dedans : je n’ai pas touché à ce satané éditeur visuel… Hum… sauf qu’en testant avec le thème par défaut, le problème s’est réglé. Damned! Le problème vient donc bien de mon thème…

A partir de là, il ne m’a pas fallu bien longtemps pour chercher du côté du fichier functions.php qui apparaissait comme le seul à pouvoir torturer le petit tinyMCE de la sorte. D’autant plus que j’utilise des morceaux du thème Sandbox dans lesquels j’aurais pu faire une coupe trop franche ou pas assez !

Je ne vais pas vous faire patienter plus longtemps pour vous livrer le coupable qui se cachait dans une fonction qui servait à insérer une vidéo Youtube via un shortcode. J’avais pourtant déniché cette petite perle chez quelqu’un de confiance ;)

J’ai donc supprimé les fonctions et tout est revenu à la normale… pendant au moins dix minutes ! le temps d’écrire ce billet, et hop, l’éditeur visuel perdait la vue à nouveau /o\ le code de l’ami burn’ n’étant donc pas fautif !

Je décidais de laisser ce petit soucis de côté pour la prochaine fois pour embrayer sur la résolution d’un problème bien plus important : mon flux RSS, invalide, provoquait des erreurs. Après une discussion sur Twitter avec Olivier Galluchot qui m’a fournit des pistes précieuses, comme supprimer tous les espaces surnuméraires dans les fichiers relatifs aux flux présents dans le dossier /includes, et tout rentrait dans l’ordre.

Cerise sur la cacahouette, en revenant corriger cet article, j’ai retrouvé un éditeur visuel en parfait état de marche…

Conclusion en forme de proverbe indien : pour réparer éditeur visuel bloqué ; casses un flux RSS ^_^

Articles sur le même sujet

Editeurs WYSIWYG : allez, les développeurs encore un effort :)

Bruno Bichet — Sat, 17 May 2008 19:05:59 +0000

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 :


  
    
      Terme 1
      Définition 1
      Terme 2
      Définition 2

Voire même qui permettrait de choisir les balises se trouvant à l’intérieur des éléments dd comme :


  
    
      Terme 1
      Définition 1
      Terme 2
      Définition 2

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 ?