Le règne du désordre

Vous avez sûrement, dans votre expérience, récupéré un jour la gestion d’une CSS qui ressemble à ça :

.new-left, .new-right {
   background:url('/layout/images/icon-new.png') 0 0 no-repeat;
	 padding-left: 30px; /* pas touche */
  display: inline-block;
  min-height: 30px;
zoom:1; /* IE */
}
.new-right {
float:left;
  display: block; /* sait pas, mais pas touche */
 background-position: 100% 0;
  padding: 30px;padding-left:0;
        }
/* ================= */
/* NEW */ .jpg {line-height: 13px; min-height: 1em; }
/* NEWNEW */ .jpg {line-height: 13px; min-height: 1.2em; }

C’est l’exemple parfait des CSS telles qu’on les produisait avant : le langage étant très permissif et l’intégration étant le dernier maillon de la chaîne, les CSS étaient un tas de ruines ou la seule règle qui régnait était… le désordre.

De nombreuses voix se sont élevées contre ces mauvaises pratiques. Imaginez-vous récupérer cela sur une intégration complexe, c’est particulièrement désagréable :

• l’indentation est catastrophique et gêne la lisibilité ;
• les propriétés ne sont jamais dans le même ordre ;
• les parties ne sont pas clairement identifiées ;
• on en sait pas trop où l’on se situe dans le projet ;
• et surtout, on ne sait pas comment intervenir sans que ce château de cartes ne s’effondre !

Avec la complexité montante des projets, il devient capital de s’organiser et de s’accorder sur des conventions pour rédiger des CSS. Non seulement les conventions aident à la conception, mais elles rendent la maintenance beaucoup plus aisée. Ajoutons à cela que si vous devez reprendre une CSS, vous serez plus enclin à la maintenir soigneusement si elle est rangée au millimètre.

Des exemples de conventions

Il en existe plein, presque autant qu’il existe de développeurs front-end ! :)

Ces conventions peuvent parfois surprendre par leur raffinement de détails, mais cette rigueur amène un confort sans égal pour reprendre une feuille de style, et même la concevoir.

En général sont décrits :

• les différents blocs de commentaires (structure globale, sous-partie, aide, etc.) ;
• l’indentation choisie : espaces/tabulations, le nombre de ces dernières, etc. ;
• la notation des propriétés, selon qu’elles soient préfixées ou non, sur une simple ligne s’il y a une une unique propriété ;
• l’ordre des propriétés ;
• les classes atomiques à disposition le cas échéant ;
• etc.

Voici quelques exemples de conventions :

• les conventions CSS de Github ;
• des principes d’écriture pour des CSS cohérentes et idiomatiques (traduction francophone des conventions CSS de Nicolas Gallagher) ;
• Improving Code Readability With CSS Styleguides, sur Smashing Magazine.

Si vous utilisez des frameworks CSS, en général ils posent également leurs conventions. Par exemple, vous pouvez étudier celles de KNACSS, qui sont un concentré de bonnes pratiques : Présentation du framework KNACSS.

BEM (Block Element Modifier en anglais) propose entre autres conventions une idée intéressante pour CSS : indiquer chaque module, chaque élément (enfant) du module, et chaque « modifieur » du module directement dans la façon de nommer ces classes :

.block{}
.block__element{}
.block--modifieur{}

Ainsi il est possible de comprendre la structure générale et les modifications apportées à cette dernière directement en observant la structure même du HTML/CSS.

Ajoutons à cela que ces conventions ont des effets qui dépassent souvent le cadre strict de l’écriture des feuilles de style : par exemple, le fait de mettre une seule propriété par ligne facilite grandement la visualisation des changements sur un outil de gestion des versions du code, comme Git.

Avec plusieurs propriétés sur la même ligne comme dans l’exemple ci-dessous, comment savoir rapidement ce qui a exactement été modifié sur la ligne en question ?

Par contre, on voit clairement dans cet exemple ci-dessous ce qui a été modifié pour chaque ligne.

D’autres outils peuvent également favoriser cet effort de structuration : typiquement, les préprocesseurs comme Sass ou LESS permettent de scinder les fichiers CSS en plusieurs sous-fichiers, ce qui permet d’isoler chaque grande partie de votre structure de votre feuille de style. Ainsi, la recherche et/ou la modification sera plus efficace dans de plus petits fichiers.

Des guides de styles

Un ou plusieurs documents recensant les guides de style doivent être créés, même et surtout si c’est à usage interne. Les éléments de typographie, les différents blocs, le layout général, etc. sont ainsi renseignés et explicités.

En voici un exemple : des guides de styles pour votre intégrateur.

Déjà cela facilitera la réalisation de la CSS : le développeur front-end aura une vision d’ensemble et détaillée du travail du web designer, et sera plus enclin à le retranscrire fidèlement. Il aura également une vue d’ensemble des divers modules à produire.

Ensuite l’intervenant qui arrive en cours de projet aura un document de référence permettant de s’y retrouver. Ajoutons à cela qu’une CSS bien ordonnée et bien commentée facilite grandement sa maintenance et son évolution.

Enfin… pourquoi ne pas remettre ce document à votre client ? C’est un gage de sérieux et de professionnalisme, le tout mâtiné de pérennité, autant pour le site que pour ses CSS. Il serait bien dommage de vous priver d’autant de bénéfices… et vous pourriez être l’agence qui reprend le site.

Ce concept de guides de style est même poussé bien plus loin dans certaines approches, on parle maintenant de « styleguide driven development » : du développement conduit par guides de style.

En voici quelques exemples :

• Kalei - Style guide
• Style Docco
• Automatic living styleguide
• Style Guide Driven Development

Cette approche permet de poser la documentation en nœud central via un guide de style vivant. Cela peut paraître surprenant, mais en même temps, cela règle de facto la mauvaise pratique qui consiste à remettre à la fin du projet (ou aux calendes grecques) la production des guides de styles.

Conclusion

Comme vous avez pu le voir, il existe plein de conventions et d’outils possibles, les meilleurs étant à mon humble avis ceux que l’on choisit et auxquels on se tient.

Qu’on se le dise, nos CSS doivent être bichonnées et tenues avec la plus grande rigueur !

Références, compléments

• Les conventions CSS de Github
• Principles of writing consistent, idiomatic CSS
• Improving Code Readability With CSS Styleguides
• General CSS notes, advice and guidelines
• Style Guide Driven Development
• Des guides de styles pour votre intégrateur
• La méthode FUCSS

Note

Cet article fait partie de la série « Grands principes de construction moderne de CSS ».