Archives mensuelles : juin 2011

Refactoring CSS

On trouve facilement des ressources sur le refactoring sur internet, à commencer par les sites de Martin Fowler et de Ward Cunningham. Cependant je n’ai pas trouvé de page dédiée au refactoring des feuilles de styles CSS. Ces fichiers peuvent cependant, autant que du code écrit dans un langage impératif, devenir énormes, redondants, ou comporter des erreurs et inélégances.

J’ai donc établit une liste (non exhaustive) de code smells CSS avec les refactorings associés, si applicable.

1) Duplications de propriétés.

Une même propriété est appliquées plusieurs fois sur un élément, via des sélecteurs différents.

Exemple :

body * { margin: 0;}
#mainContainer p { margin: 0; }

Refactoring :
Supprimer les propriétés redondantes, en gardant la sélection la plus générale.

2) Propriétés écrasées

Une propriété est écrasée par une autre avec un sélecteur similaire, rendant la première inutile. Il s’agit d’ailleurs d’une autre forme de duplication.

Exemple :

#main a { color #336; } /* Écrasée par la suivante */
...
div#main a { color #666; }

Refactoring :
Supprimer les déclaration inutiles.

3) Duplications de sélecteurs.

Un même sélecteur est utilisé plusieurs fois dans la feuille de style, pour appliquer des propriétés différentes aux même éléments :

#content form label { color #666; /* The color of the beast */ }
...
#content form label { float : left, display : block; width : 10em; }

Refactoring :
Rassembler les sélecteurs dupliqués :
 #content form label { color #666; float : left, display : block; width : 10em; }

4) CSS trop longue

Un fichier trop long par rapport à son utilité ressentie est mauvais signe. Il peut être redondant, mal écrit ou contenir des style propres à certaines page ou à certain navigateurs.

Refactoring :
– Appliquer les autres refactorings pour réduire les redondances.
– Séparer les propriétés spécifiques (fix et hacks) à un navigateur ou à une page précise dans des fichiers à part.

5) Code mort (sélecteurs non utilisés)

Vous avez du code dans votre feuille de style qui n’est utilisé dans aucune page du site. Ce code ne sert à rien, si ce n’est à rendre le fichier plus long et moins lisible. Utilisez un outil de versionning pour garder l’historique de votre travail.
Refactoring :
Supprimer le code mort.

6) Mauvais noms de classes ou d’identifiants

Les noms sont toujours un problème. Un bon nom doit être court, mais pas trop, suffisamment expressif et précis pour être compris par le lecteur et les noms doivent être consistants entre eux (suivre les même conventions).

Refactoring :
Renommer. La correction implique ici potentiellement une modification du markup html.

7) Sélecteurs liés non rassemblées au sein du fichier

Lors du design initial on écrit à la suite les propriétés relatives à une même partie de layout. Mais il n’est pas rare d’en ajouter ensuite à la fin ou au début du fichier au cours de la vie du projet. Cet éclatement nuit à la lisibilité.

Refactoring :
Ranger les déclarations en regroupant celles qui concernent les même éléments.

8 ) Classes liée au style (red, padTop8, …)

C’est un défaut répandu en CSS : l’intégrateur crée des classes qui porte le nom du style associé, par exemple red pour mettre le texte en rouge.

Cette démarche a plusieurs inconvénients. D’abord cela alourdi le markup avec beaucoup de classes qui pourraient être évitées, ce qui le rend moins lisible.

Ensuite on viole le principe de séparation du contenu et de la présentation. Il n’y a pas une grande différence entre ajouter une classe red à un élément ou un attribut color avec la valeur red. Du coup il est très difficile de modifier le design d’une page puisqu’on doit retoucher tout le html plutôt que juste la feuille de style.

Surtout, quand le design changera, que par exemple les textes préalablement en rouge deviendront verts, l’intégrateur aura l’air malin avec sa classe red qui met le texte en vert.

Exemple :
<p class="red bold">Un email doit contenir un caractère '@'</p>

.red { color : red; }
.bold { font-weight : bold; }

Refactoring :
Supprimer les classes de présentation et appliquer le même style aux éléments via des sélecteurs plus liés à la structure de la page (sémantique, …) qu’à son design.
Exemple (en reprenant le code ci-dessus) :

<p class="errorMessage">Un email doit contenir un caractère '@'</p>

.errorMessage { color : red;  font-weight : bold; }

9) Texte sous forme d’image

Une image a été utilisée pour afficher du texte, par exemple pour un titre ou un bouton. Le texte ne sera donc pas visible si l’image n’est pas chargée, ne sera pas sélectionnable, ni indexable par un moteur de recherche, ni lisible par un synthétiseur vocal.

Refactoring :
Si la police est disponible sur les système cible, que les navigateurs ciblées supporent @font-date ou qu’une police proche y existe, remplacer l’image par le texte, avec éventuellement une image de fond.

Penser également qu’il existe des propriétés comme text-shadow ou text-transform pour jouer sur les caractères.

Si l’image est vraiment trop complexe, utiliser quand même du texte, mais en le faisant sortir du contenant et avec l’image souhaitée en image de fond :

text-indent:-999px;
overfow-hidden;
background-image: url('...')