DanielR

Salut ! Content d'apprendre que tu prévois d'utiliser WYM ! Bon travail pour ton CMS et tiens nous au courant. Comme souvent, il fait bien gris et humide en Belgique. Mais on garde le moral !

S'il faut un minimum de sécurité, oublie les méthodes javascript ou css, il faudra faire ça du côté serveur.

J'ai déjà eu ce problème sur un site que j'ai réalisé: j'avais un décalage de +- 20px d'un élément div. Ca n'arrivait pas à tous les coups, et ça disparaissait lors d'un rafraîchissement de la page. On dirait cependant que le problème été réglé depuis Firefox 1.5.

En outre, lorsque tu as un code qui n'est pas valide, tu t'exposes à des problèmes dus au fait que les navigateurs vont devoir en partie "interpréter" ton code avant de l'afficher, et différents navigateurs peuvent très bien interpréter différemment. Cela peut entraîner des bugs inattendus au niveau de l'affichage, ou encore au niveau du comportement de tes scripts. Sibelius a raison quand il te conseille de ne pas placer de scripts dans tes documents. Malheureusement il faut admettre que les sites mélangeant du javascript au code html sont bien plus répandus que ceux qui font ça proprement en faisant bien la séparation. La bonne méthode consiste à éviter toute présence de code javascript dans ta page, et seulement d'appeler le(s) fichier(s) .js. Dans ce fichier .js tu peux utiliser des méthodes telles que: getElementsByTagName ou getElementById pour atteindre des éléments présents dans ta page pour pouvoir leur attacher des comportements javascript. Cette manière de procéder fait partie d'une approche que l'on appelle "javascript non intrusif", je te laisse chercher des infos si le sujet t'intéresse, mais n'hésite pas non plus à poser des questions.

Je tiens aussi à vous dire un tout grand et retentissant merci ! Par rapport à ce que jf_h a déjà dit, je souhaiterais développer quelques points: L'approche de WYM editor, qui consiste à faire abstraction de la présentation finale permet d'attirer l'attention de l'utilisateur sur la structure du document, et donc de lui en faire prendre conscience. L'utilisateur aura donc moins tendance à faire du "bricolage". Pour le designer, la mise au point des css devient plus facile, et les "comportements du site" lors d'évolutions futures sont plus prévisibles. En outre, par son approche, WYM editor a la possibilité de rester très simple au niveau conceptuel: Tout ce que fait WYM editor, c'est travailler avec des balises simples (h1, h2, h3, p, ul, li, ...) sans prise de tête comme on peut le voir dans d'autres éditeurs, où on peut régler des tonnes d'attributs (couleur de fond, alignement, etc.), lesquels se trouvent mélangés au code. Avec WYM editor, il suffit simplement d'assigner aux éléments des classes que le graphiste aura prédéfinies. Le graphiste peut aussi créer des restrictions: telle classe s'appliquera seulement aux élément "p", telle autre classe seulement aux "ul". De nouveau on empêche l'utilisateur final de faire n'importe quoi, tout en lui facilitant l'édition. Dans le cas d'un client, celui-ci aura moins d'appréhensions à confier les mises à jour à un de ses employés. Grâce à la conformité stricte XHTML, ce qui sort de WYM editor (et avec un coup de main de tidy) est du XML bien propre, ce qui veut dire, comme l'a dit jf_h, que les traîtements XSLT sont possibles. L'intérêt de la chose ne saute peut-être pas aux yeux, voici exemple parlant: Nous avons été confrontés au problème d'un site où il fallait absolument des images avec légendes. Pour cela on peut utiliser une liste de définition, ce qui nous donne par exemple: <dl> <dt>(image)</dt> <dd>(légende)</dd> </dl> Sémantiquement c'est bon, et avec un petit coup de css on affiche ça comme on veut... Oui mais pour que ça ait de l'intérêt, il faut que l'utilisateur final puisse faire ça lui-même dans l'éditeur. Et c'est là que se trouve le problème: il s'agit d'une construction très difficile à implémenter dans un éditeur, et même si vous y arrivez, vous risquez d'embrouiller la personne qui devra s'en servir. Grâce au fait que le code est transformable par XSLT, il suffit que l'utilisateur insère son image, et indique une description (attribut title), ce qui reste très simple et basique. Lorsque la page est publiée, notre CMS lui applique une transformation XSLT, qui va permettre de remplacer les éléments <img src="foo.jpg" alt="bar" title="légende de l'image" /> par: <dl> <dt><img src="foo.jpg" alt="bar" title="légende de l'image" /></dt> <dd>légende de l'image</dd> </dl> On peut facilement étendre ce principe pour résoudre toutes sortes de problèmes: Pour reprendre un nouvel exemple, créer un tableau dont les lignes ont une couleur alternée devient pour l'utilisateur aussi simple que de créer un tableau puis de lui assigner une classe prédéfinie... Le reste se passe en coulisses, puisque la page finale peut être manipulée à volonté avec des XSLT. En conclusion, je dirais que grâce à cette approche dans l'utilisation des standards web, WYM editor propose une grande souplesse tout en étant moins compliqué que les éditeurs WYSIWYG habituels.

J'ai pris l'habitude de (quasiment) tout faire en css. Mais de temps en temps on tombe sur des cas vraiment difficiles. Alors parfois c'est clair qu'il vaut mieux déroger un peu à la règle, c'est pas la fin du monde non plus ! Par exemple, si tu as un site full css qui utilise exceptionnellement un petit tableau pour te faciliter la tâche dans un cas difficile, je n'y vois rien de dramatique. Dans la plupart des cas, faire des sites en css permet réellement de se simplifier la vie, d'alléger le code, de le rendre plus accessible, de faciliter la maintenance etc. Mais si tu utilises un tableau de temps en temps pour te sortir des situations difficiles, je ne vois pas le mal. Les CSS ne peuvent pas tout, alors parfois il faut choisir entre 1. modifier un choia son design pour faire un truc + facile à transcrire en css 2. chercher obstinément une solution 100% css 3. utiliser un petit tableau Le choix dépend de la situation, mais dire qu'il faut à tout prix choisir la 2ème solution, ça va en théorie, mais en pratique ça tient pas debout.

et hop, voilà qui est fait la soluce :-) Réalisé en quelques minutes. Je ne dis pas ça pour faire le malin, mais seulement pour dire que c'est seulement une façon de travailler qui est différente mais quand on a pris le pli ça devient assez rapide à réaliser. J'ai mis les styles directement dans le fichier html et non dans un fichier css externe pour que tout soit visible en affichant le code source. C'est vrai qu'au début le positionnement css peu paraître peu intuitif quand on est habitué à d'autres méthodes, surtout avec les bugs des navigateurs (principalement IE) qui ajoutent une grosse difficulté. Mais avec un peu de pratique, on sait par habitude ce qui passe ou ne passe pas dans différents navigateurs, et comment faire pour écrire directement des styles qui passent bien partout (parfois il faut un peu d'essais/erreurs, ou au pire recourir à 1 ou 2 petits hacks).

Je pense que tu devrais aller jeter un oeil à Dewplayer: Dewplayer