Prendre des conventions en CSS et les documenter

Openweb.eu.org > Articles  > Prendre des conventions en CSS et les documenter

Abstract

Si la sémantique se définit comme « un ensemble de règles et de conventions dans le but de permettre à un groupe de personnes de se comprendre », pourquoi ne pas appliquer ce concept… à la conception même des CSS ?

Article

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 ! sourire

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 :

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 ?

Modification de code CSS affiché sous Github, peu lisible

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

Modification de code CSS affiché sous Github, plus lisible

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.

Un guide de style CSS

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 :

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

Note

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

À propos de cet article

Vos commentaires

  • Ysabeau Le 8 mai 2014 à 20:52

    Ce sont les miennes qui ne sont pas terribles de CSS.

    J’imagine que je peux utiliser KNACSS avec SPIP sans autre forme de procès !

  • Ch. Onze Le 9 mai 2014 à 10:41

    Très bonne piqûre de rappel. Et merci pour les liens, je les ajoute à ma file de lecture !

  • Nicolas Le 9 mai 2014 à 12:17

    Super article merci Nicolas.

    Par contre le modifieur est généralement introduit par ’—’ et non ’__’ comme tu l’indiques dans ton exemple :

    .block
    .block—element
    .block__modifieur

    Merci encore !

  • Nicolas Hoffmann Le 9 mai 2014 à 14:32

    Ysabeau : oui, je vois pas ce qui l’empêcherait sourire

    Ch. Onze : de rien.

    Nicolas : autant pour moi, le pire c’est que le lien indiqué juste en-dessous donne bien la bonne version. C’est corrigé merci sourire

  • Jérémy Le 11 mai 2014 à 21:57

    Article très intéressant !

    Les guides de styles tendent à se démocratiser surtout sur des projets ou plusieurs personnes interviennent.

    Pour ceux qui utilise Grunt ou prévoit de l’utiliser je conseille grunt-styleguide (https://github.com/indieisaconcept/grunt-styleguide), permettant d’utiliser KSS ou Style Docco.

    Je travaille actuellement sur le design et l’intégration d’une interface pour une plateforme d’affiliation et la génération automatique d’un styleguide (qui sera ensuite fourni aux équipes de développement) en prenant seulement quelques minutes pour commenter le CSS qu’on est en train de faire, c’est juste génial.

  • Jérémy Le 23 mai 2014 à 12:58

    En complément de mon commentaire précédent, je vous partage un article que j’ai écrit sur la "Génération de guide de styles avec Grunt" : https://medium.com/@JeremyRaffin/4abccdcbab29

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom