htmlarea et cie
Par Laurentj le jeudi, mars 18 2004, 09:22 - Technologies Web - Lien permanent
Pour des applications web, ou des backends, on utilise l'élément html textarea pour pouvoir saisir du texte. L'un des plus gros reproche que me font les clients quand ils saisissent leur texte : ce n'est pas WYSIWYG. On ne peut pas mettre en gras, en italique ; On ne peut pas spécifier la police de caractère, choisir la taille des caractères, souligner etc.
La première solution serait de leur permettre de saisir du HTML. Mais c'est trop compliqué, nécessite de se former au langage, trop gros risque d'erreur, donc trop gros risque de voir les mises en pages détruites, inaccessibles etc... Je sais par expérience que la plupart du temps, les utilisateurs ne veulent pas entendre parler de HTML ou autre. Ils veulent comme dans Word. Point. Donc oublions cette solution.
La deuxième solution, dont je suis un adepte inconditionnel, et de permettre la saisie en syntaxe wiki. Ce n'est pas encore parfait pour l'utilisateur de base, il faut un léger apprentissage mais c'est déjà plus simple et plus "user friendly" que la saisie du code HTML. Au niveau implémentation, pas de problème, une petit coup de WikiRenderer en PHP, et hop, vous avez le source HTML valide (ou autre format) à integrer dans vos pages.
La troisième solution, c'est d'utiliser des scripts tels que Htmlarea, en Javascript, à intégrer dans votre formulaire. Là, c'est parfait pour l'utilisateur de base, c'est du 100% WYSIWYG. Il tape son texte comme il a l'habitude de faire dans Word. Il le transforme comme il le veut, il met les couleurs qu'il veut, les polices qu'il veut etc... En coulisse, Htmlarea produit du HTML.
Mais personnellement, je pense que ce n'est pas une super bonne idée. Passons sur le fait que cela ne produit pas forcément du code valide, surtout quand notre site est en strict (les balises font, center et compagnie, générées par Htmlarea ne sont pas les bienvenues). On peut je pense hacker Htmlarea pour qu'il produise un code plus propre (utiliser l'attribut style et y générer des CSS), même si l'implémentation risque d'être un poil plus compliquée ;-).
Ce que je reproche le plus à ce genre de solution :
- C'est que cela permet à l'utilisateur de choisir lui même la présentation. De quoi mettre tout en l'air le design du site. Et le résultat peut aussi ne pas être en adéquation avec ce qu'à taper l'utilisateur : en effet, les CSS éventuellement utilisées sur le site risquent de modifier l'apparence une fois que le texte est affichée en situation réèlle (les backends n'ont pas forcément le même design que le site). Il faut prévoir une prévisualisation.
- On stocke le texte saisie, formaté en HTML, avec tout ses attributs et balises de présentation. Qu'en est-il de l'évolution du site ? Un jour on change le design du site, et voilà que la mise en page du texte saisie par Monsieur Duchmol, dans lequel il a mis fièrement un titre en Times New Roman 20pt, ne va absolument plus du tout avec le nouveau design : il faut reprendre un à un tous les textes saisies pour les remettre en page.
- La réutilisation des données dans un autre contexte ou un autre site pose un problème supplémentaire. On pourrait bien sûr utiliser par exemple XSLT pour transformer les textes saisies en d'autres format, mais il faut s'assurer que le html est bien formé et valide. Pas simple
Bref, des outils comme HtmlArea peuvent limiter serieusement l'usage de CSS, et surtout rendre problèmatique la pérénité des données. Je pense que si on utilise ce genre d'outil, il faut :
- être certain que cela produit du code valide
- limiter les possibilités de mise en page, en permettant seulement d'indiquer la structure du texte, comme en wiki : indiquer que ceci est un titre, cela est un paragraphe, une emphase ou encore une liste etc.. Et donc oublier les fonctionnalités gadgets comme choisir une couleur, une police de caractère, sa taille etc...
Voilà une bonne idée de hacking sur htmlarea, non ? ;-)
Commentaires
C'est certain.
Mais cette idée ne s'appelle-t-elle pas NVU ? :D
Et une solution comme : http://www.mozilla.org/editor/midasdemo/ ? Ca parait pas trop mal ?
C'est vrai que c'est chiant cette comparaison constante avec Word. C'est ce qu'on m'a dit quand je suis arrivé à mon stage : "tu verras, l'éditeur de l'intranet, il est pas compliqué, c'est comme Word en gros." En plus Word c'est quand même pas une référence, ni en terme de simplicité, ni en terme de standard, ni en terme de conformité avec quoi que ce soit.
c'est à peu près la reflexion que j'ai suivi ces derniers jours en pensant aux possibilités à donner à l'utilisateur dans un CMS (ou un truc du genre). j'étais arrivé à une autre solution à mi-chemin entre le htmlarea et le wiki : les boutons de mise en forme du texte rajoutent en fait les balises wiki au texte sélectionné. c'est une sorte d'aide à la syntaxe wiki. L'avantage c'est qu'un simple textarea et quelques fonctions javascript (en respectant le DOM bien sûr ;)) suffisent.
ce qui est bien dans les blogs c'est qu'on peut penser tout haut :)
Un générateur de code wikki ça aide l'utilisateur à ne pas apprendre par coeur les codes. Mais finalement ils ne sont pas très complexes, ce n'est pas vraiment le problème je pense.
L'intérêt d'un htmlarea qui n'utilise que les balises sémantiques (et pas la mise en forme) c'est que ça reste WYSIWYG, la CSS globale du site se contentant d'appliquer les mises en formes habituelles.
Ceci dit Laurent, je conteste ta comparaison avec MS Word. MS Word c'est exactement comme le HTML : tu peux appliquer bêtement des mises en forme, ou tu peux dire "ceci est un titre, ceci est une liste, ceci est un sous-titre" et appliquer des styles sur tout ça. Personnellement je suis convaincu par l'utilisation des styles, et que ce soit MS Word ou du HTML, c'est toujours ce qu'il y a de plus efficace.
Que l'on passe par une aide à la syntaxe HTML ou à la syntaxe Wiki, l'utilisateur ne doit pouvoir générer que du balisage structurel, et pas présentatif (couleurs). Mais, quelque-soit l'outil, je vois mal comment empêcher quelqu'un d'entrer un <h1></h1> injustifié, en plein milieu d'un texte, juste pour que ce soit en gras et en gros. Le fond du problème, c'est aussi " d'éduquer " l'utilisateur... Ce qui n'est pas rien ;-)
Eric : Oui, on peut utiliser des styles dans Word. Mais je te ferais remarquer deux choses :
Et si vous n'en êtes pas persuadé : essayez de tester PageMaker . Vous avez là un logiciel de PAO, qui est on ne peut plus ergonomique et efficace dans la gestion des styles. C'est d'ailleurs pourquoi je l'ai utilisé pendant de nombreuses années à la place de Word. C'est ce que j'appelle un vrai traitement de texte.
Anubis : NVU ?
Euh.. le but n'est pas du tout le même ;-) Le but de Nvu : éditer des pages web. Le but des formulaires HTML avec htmlarea : editer des données, des textes (qui peuvent être déstinés à être intégrer dans des pages web automatiquement).
rdd: oui midasdemo est bien mieux coté conforme au (x)html/strict. Mais... Il n'est utilisable que dans Moz helas... Alors que htmlarea 3.0 beta est utilisable sur IE et Moz.
Au fait LaurentD, ton site il est inaccessible à mozilla depuis quelques jours. En fait, ça le fait monter en charge, à 90% de CPU, rien ne s'affiche etc.. Et ça le fait dans firefox aussi.
(mais pas konqueror)
Il me semble que htmlArea s'appuie sur des fonctionnalités propriétaires des navigateurs. Pour Mozilla, c'est Midas (cf. commentaire de rdd) qui se charge de ça.
Hum... D'accord pour dire que la gestion des styles dans Word est tout sauf pratique. Mais le fait que X% des utilisateurs ne s'en servent pas ne prouve pas grand-chose sur le fond. Juste que c'est mal conçu du point de vue ergonomie.
A propos du problème de mon blog dans Mozilla/FireFox : curieux... ça semble lié à la CSS "Libération" (temporaire). Mais le problème ne se pose apparemment que sous Linux ? Pas le temps de creuser...
J'ai posté sur ce sujet il y a quelques temps sur la liste des pompeurs : http://fr.groups.yahoo.com/group/pompeurs/message/7472
J'ai étudié en détails le code sources de mozile, mais c'est inutilisable avec Internet Explorer parce que la conception est orienté uniquement Gecko DOM (objets avec des prototypes etc ...)
J'ai également regardé HTMLArea. Malheureusement, il ne fonctionne pas dans mon firefox ... Il faudrait que je reteste pour étudier plus en détails.
Mais l'idée d'un éditeur WYSIWYG utilisable dans le navigateur et produisant un code XHTML sémantique me chatouille depuis plusieurs mois ... Si quelqu'un veut lancer un projet, à partir d'un script existant ou à partir de rien, je suis partant, mais mon emploi du temps est déjà bien rempli !
En tout cas, d'après mes recherches, ca n'existe pas, et c'est un gros manque, parce que beaucoup de projets pourraient en profiter.
Pour ce qui est du résultat qui peut ne pas être en adéquation avec ce qu'a tapé le client, il suffit d'appliquer les mêmes styles à la boite d'édition qu'aux pages de ton site. C'est juste une feuille de style à selectionner et à adapter un poil.
Bonjour,
Laurent D, je viens d'essayer ton site avec FireFox et Win XP... même problème : page vide et gros ralentissement de toutes les fonctions du navigateur, pourtant je peux afficher la page source.
Amicalement, Monique
4° Solution, utiliser composite http://composite.mozdev.org/ ou la version de viet-dev : http://vietdev.sourceforge.net/vinamozie/mo_installer.php Pas besoin de recoder l'appli.
Tiens en passant, quelqu'un sais s'il existe une macro pour openoffice permettant de transformer un texte formaté en syntaxe wiki ? ca ca pourrait etre bien.
Ce site est fort intéressant... Je voulais connaître des détails à ce propos !
Je suis moi-même webmaster d'un moteur de recherche entièrement gratuit destiné aux webmasters souhaitant voir augmenter efficacement leur trafic ! Cela fait presque un que mon site est créé, et il commence réellement à avoir un SACRE SUCCES et j'en suis bien content....