Rendre modulaires les feuilles de styles
Les feuilles de styles CSS permettent de modifier l'apparence visuelle d'un site web sans modifier le code Html de la page (voir
CommentPersonnaliserGraphiquementWikiNiEn10Minutes). Pour Wikini, il n'y a que 2 fichiers CSS : un pour les très vieux navigateurs et un pour les autres. On peut déjà se demander pourquoi cette différenciation. En effet, les navigateurs ne supportant pas certaines règles CSS ignoreront tout simplement une partie du contenu de
wakka.css mais exploiteront ce qu'ils reconnaissent. Il semble donc qu'on peut supprimer
wakka.basics.css sans aucun scrupule, on y gagnera en maintenabilité. D'ailleurs, un petit
diff nous dit que
wakka.css contient un certain nombre de styles absents dans l'autre : oubli ou volonté délibérée ?
Ensuite il semblerait intéressant de scinder le fichier CSS en plusieurs fichiers plus petits notamment du fait des
DiscussionsNormeDeCodageCSSPourWikiNi, le contenu du fichier principal serait limité à des
@import url(<machin>.css). Certes tous les navigateurs ne reconnaissent pas cette règle pourtant issue de CSS version 1. Cependant un rapide tour chez
CSS-only Filters Summary montre que rares (et antedéluviens) sont les navigateurs qui ne reconnaissent pas cette règle CSS - il s'agit de Netscape 4.0x et Konqueror 2.0.
Pour la modularisation des fichiers CSS
- des fichiers CSS plus petits donc plus faciles à lire
- des fichiers spécialisés (mise en page, couleurs & aspect, actions, ..) donc plus facile de s'y repérer et...
- plus facile de s'échanger des thèmes de couleur ou de modifier un thème de couleur, notamment pour les adeptes des FeuillesDeStyleMultiples
- plus facile d'intégrer une action et de la personnaliser
- on pourrait en profiter pour insérer des CSS spécifiques à IE, je détaille plus bas l'intérêt de la manoeuvre
Contre la modularisation des fichiers CSS
- multiplication des fichiers de travail pour le développement
- on ne saura pas toujours quelle propriété va dans quel fichier
- il y a rique de multiplication des requêtes HTTP si les navigateurs ne mettent pas les fichiers en cache
Exemple de structure de fichiers CSS
wikini\css\
- global.css -> CSS générales sans id ni class (marges de BODY, HTML, DIV, etc.)
- layout.css -> contrôle la mise en page (positionnement, tailles de caractères)
- look-n-feel.css -> couleurs et bordures, polices
wikini\css\actions\ -> CSS liés à une action
- include.css
- trail.css
- ...
wikini\css\custom\ -> différenciation page d'accueil, développements perso, adaptation des actions, etc.
wikini\css\ie\ -> ne seront lues que par IE
- ie-50.css
- ie-55.css
- ie-60.css
- ie-all.css
Note :
IE et les CSS
Il est fréquent d'avoir à modifier les CSS conformes au W3C pour que ça marche bien dans IE. Le problème le plus courant est certainement le modèle de boîte (
http://css-discuss.incutio.com/?page=BoxModelHack) mais il y a aussi le classique de la taille de la police
small qui est trop grosse dans IE. Bref, un rendu impeccable dans les Gecko / KHtml / Opera ne donne pas forcément un beau résultat dans IE... Alors il faut que les CSS pour IE soient modifiés : c'est là que les CSS hacks entrent en jeu (
http://css-discuss.incutio.com/?page=CssHack). Les problèmes avec ces méthodes sont que cela rend obscur le code CSS, que cela peut empêcher la validation CSS et surtout que quand IE7 sortira un jour, il faudra peut-être revoir tout ça... L'astuce la plus élégante consiste à plutôt utiliser des commentaires conditionnels (
http://www.dithered.com/css_filters/html_only/conditional_comments_ie.html), une idée farfelue de MS mais pour une fois utile puisqu'on peut charger par ce biais des fichiers CSS spécifiques à une ou plusieurs versions de IE. Ces fichiers modifient alors les quelques attributs qui ne vont pas bien dans IE.
Discussions
Je trouve que l'idée n'est pas mauvaise, et d'ailleurs tant qu'à faire tout d'un coup, pourquoi pas
RendreModulairesLesFeuillesDeStyle ? Ça devrait être assez simple: il suffit de générer la feuille de style principale en php, simplement en lisant un répertoire (par exemple
stylesheets/) et en retranscrivant les noms de fichier
@import url("stylesheets/fichier1.css"). On pourrait même faire des vérifications sur l'identification du navigateur via php (quoi que cette dernière idée n'est probablement pas si bonne puisque beaucoup de navigateurs, robots etc. contiennent IE dans leur user-agent...). --
LordFarquaad
La génération automatique du fichier
wakka.css est un truc auquel j'avais pensé à vrai dire, mais comme j'ai vu qu'on cherche à optimiser au maximum le temps de réponse du moteur Wiki, je me disais donc que l'idée est encore à mûrir. Néanmoins comme tu t'y connais certainement beaucoup plus que moi en Php, j'ai l'impression que c'est tout à fait jouable. Pour moi ce serait un truc fabuleux : tu veux ajouter des CSS perso, ben tu crées un fichier CSS dans un sous-répertoire de
/css et c'est tout ! Mise à jour du Wiki ? Pas de problème, ton fichier n'est pas concerné !!! Bon le seul problème, c'est que c'est totalement incompatible avec les versions précédentes de Wikini, mais on n'est pas encore en 1.0, non ? --
JmPhilippe
- Lire un répertoire et afficher la liste des fichiers qu'il contient (sous une forme ou une autre) est très rapide... et simple ;-) Le seul truc c'est qu'on ne pourrait pas nommer le fichier wakka.css car il faudrait alors configurer le serveur (par exemple via htaccess) pour qu'il interprète les fichiers css comme du php, et ça, c'est pas toujours faisable. Mais rien n'empêche de le nommer wakka.css.php. Pourquoi incompatible avec les versions précédentes ? Il suffit de créer un fichier dans le répertoire /css qui importe l'ancien fichier wakka.css automatiquement... mais bon, je pense qu'un administrateur technique devrait savoir déplacer son wakka.css dans le répertoire /css tout seul comme un grand :-j -- LordFarquaad
- T'as sûrement raison, ce n'est peut-être pas si problématique au moins dans un premier temps. Les administrateurs les plus pointilleux pourront bien passer 1 heure à éliminer les redondances entre leur wakka.css et les CSS de la nouvelle version. Les autres se contenteront de déplacer le fichier. -- JmPhilippe
- En fait je n'avais pas tellement songé aux redondances (qui ne posent pas de problème d'incompatibilité), mais en fait la feuille de style actuelle ne contient que très peu de styles spécifiques me semble-t-il, je crois qu'elle pourrait donc être conservée en grande partie dans un seul fichier, se nommant toujours wakka.css. Dès lors en déplaçant son ancien wakka, cela écraserait le nouveau ce qui éviterait tout problème de redondance...
- Par contre un autre problème est l'ordre des feuilles de style: une feuille de style B pourrait très bien redéfinir d'une autre manière certaines choses définies dans une feuille de style A; mais si l'ordre est inversé, l'effet ne serait pas du tout le même... -- LordFarquaad
- C'est clair qu'il faut imposer un jeu de fichiers CSS obligatoire et un ordre. NB: quand je parle d'incompatibilité, ce n'est pas au sujet du contenu CSS mais sur le fait que le fichier wakka.css disparaît en quelque sorte, ce qui n'empêche effectivement pas de continuer à l'utiliser. -- JmPhilippe
Pour ma part, je ne suis pas très favorable pour scinder les CSS en plusieurs fichiers : a mon sens 1. cela complique leur développement (obligation de travailler sur plusieurs fichiers en même temps ; immanquables problèmes de découpage, etc.) ; 2. cela multiplie les requêtes HTTP et affecte donc un peu les performances. L'avantage de wakka.css actuel c'est que la modification des styles est simple. Idéalement, les hacks devraient être les moins nombreux possibles voire inexistants. Dans certains cas, il vaut mieux se dire "tant pis pour tel navigateur" si le problème n'est pas fondamental : par exemple dans le cas de la taille de la fenêtre d'édition, j'ai très envie de dire : tant pis pour ceux qui ne le gèrent pas du moment que la CSS est standard et que cela n'est pas préjudiciable pour eux. --
CharlesNepote
- C'est vrai qu'on fait déjà tout ce qu'on veut actuellement avec une seule feuille de style... Quand j'y pense le seul intérêt c'est de pouvoir ajouter une feuille de style lors de l'ajout de plug-ins, plutôt que d'avoir à éditer wakka.css, ce qui n'est actuellement pas du tout nécessaire... Par ailleurs je n'ai pas l'impression que tous les navigateur mettent systématiquement en cache les feuilles de style dont ils ont besoin, donc c'est vrai que ça risquerait d'augmenter fortement le nombre de requêtes HTTP... Et c'est encore pire s'il y a de la redondance dans les feuilles de style !
- Sinon je suis aussi contre les hacks, et même pour laisser tomber les anciens navigateurs (on parle souvent de NS4 qui ne gère pas pas mal de choses...). Donc pas de hacks dans la feuille de style, et juste à la limite des trucs comme les commentaires conditionnels pour IE, qui ne se basent sur aucun mauvais fonctionnement de navigateur et restent valides tout en étant relativement clairs. -- LordFarquaad
- L'autre intérêt de scinder est qu'on peut proposer des feuilles de styles qui ne changent que la mise en page, et d'autres que les couleurs. L'administrateur pourrait facilement prendre les couleurs de OrangeJuice et la structure de LightBlue dans la page ContributionsCSS - pratique pour ceux qui ne veulent pas apprendre les CSS. -- JmPhilippe
- NB: pour le moment le fichier CSS n'a pas l'air trop long à "naviguer", mais une fois les retours chariots ajoutés et toutes les extensions insérées selon DiscussionsNormeDeCodageCSSPourWikiNi, ce sera beaucoup plus long, donc plus difficile de retrouver un élément. Bien sûr, si on ne fait pas ça les éléments sont plus facile à trouver, mais ce sont les propriétés qui sont difficiles à retrouver puisque qu'à la queue leuleu, non ? En tout cas c'est l'expérience que j'en ai. -- JmPhilippe
J'y connais hélas rien en PHP ni en CSS mais ça serait quand même bien que Wikini intègre par défaut une bonne dizaine de CSS permettant de choisir la mise en page.
Pour ne pas prendre de risque, il suffirait que seul l'admin puisse changer de style par un simple menu déroulant qui listerait automatiquement toutes les css contenues dans un répertoire donné.
Possible ?