Clarté du code CSS
Nous suggérons ici quelques normes et recommandations ne concernant que l'écriture du code CSS pour les feuilles de style. La mise en oeuvre se trouve sur la page
ReecritureDeWakkaCss.
Il y a pour Wikini des directives pour écrire du code PHP lisible, lequel doit produire un code Html lui aussi lisible (c'est mieux pour déboguer les pages et les CSS). Les pages concernées sont
DocDeveloppeurNormesEtRecoDeDeveloppement et
DiscussionsNormeDeCodagePHPPourWikiNi. Mais personne n'avait encore évoqué la clarté du code CSS. Certes c'est moins important que le PHP, mais quand on veut modifier ne serait-ce que la couleur d'un élément, ce n'est pas facile de s'y retrouver...
Le code CSS de Wikini
Exemple de code CSS :
.page { background-color: #FFFFFF; padding: 10px; border: 1px inset; }
.prev_alert { background-color: red; color: white; font-weight: bold; margin-bottom: 5px; }
.edit { width: 100%; height: 400px; }
.footer { background-color: #DDDDDD;padding: 5px; border: 1px inset }
.code { background: #FFFFFF; border: solid #888888 2px; font-family: 'Courier New', Courier; color: black; width: 100%; overflow: scroll; padding: 3px; }
.revisioninfo { color: #AAAAAA; padding-bottom: 20px; }
Je sais qu'on a tendance à chercher à minimiser au maximum la taille des fichiers du serveur, cependant le fichier CSS n'est lu normalement qu'une fois par session, et donc l'augmentation de sa taille pour augmenter sa lisibilité ne me paraît absolument pas handicapante. Les critiques que je formulerais sont donc les suivantes :
- les propriétés CSS mises les unes derrière les autres les rendent difficiles à lire et difficiles à trouver
- l'absence de nom de tag pour les classes et identifiants rend difficile la compréhension de ce que ça change dans la page (ex.: .edit est le lien éditer, le champ d'édition, la page en mode d'édition ?)
- l'absence de commentaires, aussi succincts soient-ils, n'aide pas l'administrateur
Je proposerais donc plutôt un code de ce genre :
div.page { /* conteneur principal */
- background-color: #FFFFFF;
- padding: 10px;
- border: 1px inset;
}
div.prev_alert { /* message prévisualisation */
- background-color: red;
- color: white;
- font-weight: bold;
- margin-bottom: 5px;
}
etc.
Au total les retours chariots doivent pénaliser la taille du fichier à hauteur d'un caractère par propriété CSS et par élément, et les commentaires disons 20 caractères par élément. Donc maximum dans les 1ko, ce n'est donc pas si dramatique (0.2s sur un modem 56k).
Par ailleurs, dans le cas où l'on souhaite modifier plusieurs éléments en même temps :
div.header, div.page, div.footer, div.copyright {
}
plutôt que de risquer une première ligne illisible, on peut opter pour cette forme :
div.header,
div.page,
div.footer,
div.copyright {
}
Discussions
Totalement d'accord: la clarté prime sur le trafic et l'espace occupé. Si jamais cela posait vraiment un problème pour quelqu'un il n'aurait qu'à réduire lui-même le fichier, mais il n'y a pas de raison pour que le fichier soit si peu clair dans la distribution officielle... --
LordFarquaad
Bon en ce moment j'explore des distributions Linux (Debian notamment), donc je n'ai pas trop le temps, mais dès que je peux je présente un 1er fichier CSS remis en forme. (je sais j'ai déjà les
title manquants à traquer dans la version CVS, mais patience...) --
JmPhilippe
Totalement d'accord. --
MdeBeaumont
- Pour ma part, je suis totalement d'accord pour un code plus lisible et plus intelligent, comme tu le proposes. -- CharlesNepote
16/05/2005 --
JmPhilippe
C'est parti ! Voir la page
ReecritureDeWakkaCss.