Mes Nos réflexions sur le code CSS de Wikini
Les CSS étant un de mes sujets favoris, je me permets de lancer une page pour discuter du code CSS de Wikini. Non pas son contenu, mais sa structure et la structure de la page (X)Html associée. Je m'inspire principalement de
Why We Love Web Standards comme base de réflexion.
Il y a déjà une proposition de structure Html associée en bas de la page
DocumentationGraphiste. Pour ce qui est du contenu du fichier CSS - ce qu'on peut mettre dedans pour ne changer que l'apparence du site, il faut plutôt consulter
CommentPersonnaliserGraphiquementWikiNiEn10Minutes, ici on parlera écriture et structure CSS.
Sujets abordés :
- la clarté du code
- la structure XHtml
La structure XHtml
Il y a un certain nombre de commentaires sur la structure proposée en bas de la page
DocumentationGraphiste. Mes commentaires sont très simples :
- il faudrait mettre des id partout car il s'agit d'éléments de mise en page qui ne vont donc apparaître qu'une seule fois dans la page
- <div id="contenu" class="page"> est pour moi une très bonne idée si la classe est destinée à indiquer dans quel type de page on est (lecture normale du Wiki, édition d'une page, prévisualisation, etc.), auquel cas il faudrait plutôt inverser et mettre <div id="page" class="preview"> puisque la classe page qui existe déjà devrait en fait être un id - noter qu'on pourrait avantageusement transférer class="preview" dans le tag BODY afin d'augmenter les possibilités CSS
- des id pour un menu, le titre de page, etc. c'est très bien, mais jusqu'où faut-il aller ?
Suite à la dernière remarque, il s'ensuit que la structure Html ne peut correctement évoluer que si on se pose la question préliminaire suivante :
- Que souhaite-t-on pouvoir différencier dans la page ?
Énumérons donc ce qu'on souhaite pouvoir modifier par CSS afin de trouver un consensus.
Ce qui est absolument nécessaire de pouvoir différencier
- nom du wiki
- nom de la page
- menu de navigation (liens en haut de cette page), qu'effectivement on pourrait scinder en menu de navigation + menu utilisateur
- pied de page, qu'on pourrait peut-être scinder aussi en menu de page (éditer, date, supprimer), menu des droits (propriétaire, permissions), menu de recherche (références, champ de recherche)
- barre d'informations (lien validation Html/CSS et Wikini)
- [A effacer] Ce travail avait été fait et oublié il y a quelques temps par LaurentLunati et moi-même : cf. LaurentLunatiSkin. Entre autre, nous avions déterminé que, sauf le "contenu" de la page, aucun autre élément n'est absolument nécessaire. Ca ne veut pas dire qu'il faut proposer WikiNi sans menu ni titres de pages ni autres, mais idéalement ils devraient pouvoir être supprimé simplement. Peux-tu essayer de regarder la page LaurentLunatiSkin et tâcher de faire une synthèse avec la tienne ? Tu as tous mes encourragement sur ce sujet qui m'intéresse aussi beaucoup. Mais attention, tu verras que le sujet est assez complexe. Je commenterai tes "options" plus tard. -- CharlesNepote
- Ok je m'y collerai. J'ai lu rapidement et visiblement il y a deux sujets : la structure XHtml (qui est d'ailleurs plus remise en cause que ce que je pensais faire au départ, mais c'est très bien !) et les templates. Il faudra certainement créer deux pages liées, ProjetDeStructureXHtml? et QuidDesTemplates? par exemple. Il ne faut pas oublier de lier la page ToutLeMondePeutMaquetter aussi. Pour ce qui est des éléments nécessaires, ça porte à confusion je reconnais, en fait je voulais dire nécessaire de pouvoir différencier, je corrige mes titres. En fait grâce aux propriétés CSS display: none et visibility: hidden, tous les éléments Html d'une page sont masquables donc optionnels ! -- JmPhilippe
- La propriété display: none est une assez mauvaise idée je trouve, car le contenu est alors généré pour rien, et apparaît tout de même sur les navigateurs ne supportants pas le css (notemment les navigateurs textes, navigateurs pour non-voyants etc.) -- LordFarquaad
- Oui bien sûr que c'est idiot de générer du code pour rien. En fait je ne savais pas que ces propriétés ne faisaient rien dans des navigateurs non visuels, c'était donc juste pour dire que quand on croit que c'est obligatoire en fait ça ne l'est jamais, mais ça n'est pas tout à fait vrai manifestement. -- JmPhilippe
Les éléments à différencier en options (i.e. discuter de l'intérêt)
- pouvoir changer les CSS selon le type de page (exemple d'application : en mode de prévisualisation, cacher menu de navigation et pied de page)
- Ceci serait donc un css qui dépendrait du Handler. Il me semble qu'il y a déjà un début de cela dans la version cvs: en prévisualisation, la page apparaît sur un fond jaune. -- LordFarquaad
- Oui l'idée est d'étendre ce système, ça me semble pas cher à programmer tout en ouvrant de grandes possibilités. Si Wikini permet à des graphistes de s'exprimer autant que dans le jardin zen, c'est plutôt positif pour son expansion (il ne restera plus qu'à trouver les graphistes !). D'ailleurs une de ses grandes forces à mon avis est de proposer un outil très ouvert sur le plan de l'apparence sans nécessiter d'apprendre un langage spécifique (des templates) qui ne servira jamais à rien d'autre. Par contre côté documentation des CSS, il faudra suivre, c'est pas le tout d'offrir de grandes possibilités, il faut aussi que ça se sache ! -- JmPhilippe
- pouvoir changer chaque élément de formulaire un par un, notamment les boutons pour bien les différencier dans la phase d'édition / prévisualisation
- Je n'ai pas vraiment l'impression que ce soit si intéressant que cela, c'est peut-être préférable de garder les choses simples; il ne faut pas en arriver à ce que la moindre balise ait son propre style, ce n'est pas le but du css... -- LordFarquaad
- En fait je me suis fait prendre déjà plusieurs fois à ne pas cliquer sur le bon bouton ou à simplement oublier de cliquer en mode prévisualisation. Depuis, j'ai le sentiment qu'il faut tout faire pour guider l'utilisateur le plus possible. Cependant tu as raison il n'est pas question de mettre un identifiant sur le bouton de recherche de texte ou celui de connexion de l'utilisateur ! Reformulons donc ainsi : dans la phase d'édition / validation, pouvoir changer chaque élément de formulaire, notamment les boutons pour bien les différencier. --JmPhilippe
- Je me suis moi aussi fait prendre une fois ou deux à oublier de valider mes modifications, mais pas dans la version 0.5, je te conseille vraiment de la tester ;-) -- LordFarquaad [Je me demandais si ça ne vaudrait pas le coup de faire un backport pour une version 0.4.4. Dans le cas de fonctionnalités aussi simple et ayant aussi peu d'impact, ça vaudrait peut être le coup... -- CharlesNepote - Pourquoi pas, même si je trouve que ce n'est pas vraiment dans la logique de la version 0.4.4... En tout cas il faudrait prendre la version 1.24 (ou la 1.25) du handler edit, car il y a eu beaucoup trop de changements après, AMHA... -- LordFarquaad]
- pouvoir personnaliser chaque tableau TABLE (par exemple celui des paramètres utilisateur pourrait être d'un look sensiblement différent de celui listant les versions d'une même page)
- Cela revient à faire une feuille de style différente pour chaque action, mais cela impliquerait aussi que chaque nouvelle action sera composée de deux fichiers, c'est moins pratique... D'autres solutions consisteraient à prévoir des classes pour l'apparence des tables, et toutes les actions utilisant des tables pourraient utiliser ces classes pour leur présentation. Dernière possibilité (ne nécessitant pas d'évolution du fonctionnement général des actions): les actions en question pourraient posséder des paramètres supplémentaires pour gérer leur présentation... -- LordFarquaad
- Je pensais plutôt à un identifiant ou une classe associé(e) au tag table, ça enlève des contraintes à ceux qui programment le Php. On peut aussi postuler d'une manière plus générale que chaque action qui insère un bloc de code Html doit le faire dans un div portant un id ou un class spécifique à l'action. Pour ma part il me semble incontournable que chaque action ait son fichier CSS séparé lorsque des CSS sont nécessaires, ça permettrait de faire assez simplement un petit script d'installation/désinstallation automatique :-D. -- JmPhilippe
- Un script d'installation/désinstallation ? Je ne vois pas trop ce que tu veux dire :-S La plupart des actions etc. ne nécessitent aucune modification, elles sont on-ne-peut-plus simples à installer... Je ne suis pas certain qu'il soit si intéressant de forcer les actions à insérer ce qu'elles affichent dans un div car cela a pour conséquence de compliquer le html résiltant et, qui plus est, de les insérer dans un élément de type bloc (par défaut, mais je ne vois pas trop l'intérêt de passer un div en ligne alors qu'il existe déja d'autres boites comme les span pour cela...). -- LordFarquaad
- Oui le div c'était une idée en l'air ! Pour l'installation/désinstallation, c'est plutôt pour les personnes qui n'y connaissent rien. Créer un site à partir d'un Wiki, éventuellement en mode blog, ça me paraît au moins aussi pratique que d'utiliser Word (mais si, il y en a qui le font !). Or quand je vois comment les Wikis prolifèrent, je ne serais pas surpris qu'à l'horizon 2010 la pratique ne soit plus de préparer son site chez soi puis le télécharger, mais plutôt de le créer / modifier / étendre directement en ligne. L'utilisateur lambda devra être capable de faire le minimum d'administration sans se prendre la tête avec Php, Css, Xhtml, JavaScript, Apache, un langage de template, etc. Et si en plus ça se fait depuis une interface web... J'ai d'ailleurs un copain qui aimerais bien avoir un Wiki sur son site, il ne connaît ni Php, ni CSS et il n'avait pas l'air très chaud quand je lui ait dit que Wikini c'était du Php - il ne m'en a pas reparlé ! --JmPhilippe
- pouvoir différencier la page d'accueil
- La page d'accueil est actuellement traitée comme n'importe quelle autre page, et ce dans le respect du ConceptToutEstPage. Je trouve qu'il ne faut pas commencer à appliquer des cas particuliers pour certaines pages en fonction de leur nom etc. Mais par contre je trouve qu'une chose qui pourrait être assez bonne serait que la HandlerShow (et d'autres comme slide show etc.) génère d'abord la page avant l'entête. Ceci permettrait d'écrire des actions qui "communiqueraient" (en quelque sorte) des informations pour la générations de l'entête. Par exemple
- Titre de la page
- Méta description
- Méta keywords
- ...
- choix d'une feuille de style ou choix d'une classe pour l'élément body.
- A partir de là on pourrait laisser l'utilisateur choisir l'apparence particulière de chaque page, notamment la PagePrincipale -- LordFarquaad
- Ça fait partie de mes préoccupations du moment. Il me semble que le web en général est trop textuel et trop peu visuel. Une page d'accueil visuelle accroche beaucoup plus qu'une page textuelle à mon avis. A vrai dire je ne pensais différencier que la page d'accueil donc ta solution me paraît plus intéressante, surtout à cause des tags meta d'ailleurs. -- JmPhilippe
- Comme je l'ai dit dans AdaptationDeLaTailleDesFenetresDeCode, la question est bien plus large et cette page n'est donc pas adaptée pour en parler plus. Je n'ai placée l'idée ici que pour éviter de se lancer dans quelques chose de beaucoup plus limité alors que les possibilités sont bien plus étendues, pour peu qu'on change diverses choses... -- LordFarquaad
- On est bien d'accord, cette section est close ! -- JmPhilippe
../..