Convention d’écriture CSS pour les projets Access42

Règles de nommage

• Employer des noms anglais : .alert au lieu de .alerte
• Indiquer tous les noms au singulier : .slide au lieu de .slides
• Utiliser uniquement le trait d’union : .open-popin au lieu de .open_popin
• Donner des noms pertinents aux éléments : #eventau lieu de #block-block-1
• Utiliser les classes et identifiants comme nom d’images de fond : body.png au lieu de fond.png
• Privilégier les intitulés courts : #slideshow-control au lieu de #playpause_slideshow_slider_block-3
• La classe .sr : rend invisible un élément mais utilisable par les lecteurs d’écrans, ne pas remplacer par du visibility:hidden ou du display:none surtout.
• Toute classe commençant par .is-* : classe commençant par is- pour les classes d’état. Par exemple : is-hidden, .is-expanded, etc.

Choix des sélecteurs

• Choisir le sélecteur le plus court possible (remonter le moins de générations possible). Pour cela, on privilégie l’ajout de class sur les éléments pour les sélectionner directement (surtout lorsque la nature du sélecteur n’est pas prédictible).
• Sélectionner les éléments dans la mesure du possible par une class, plutôt que par un nom d’élément ou par un id.

Découpage modulaire

Dans la mesure du possible, on procède à un découpage modulaire des éléments. Ceci n’est pas toujours possible, voire contre-productif (nom de classe à rallonge parfois). Mais dans la majeure partie des cas, cela permet d’obtenir des noms de classe explicites.

.tool-block   { ... }
.tool-block-settings   { ... }
.tool-block-summary   { ... }

Post-processeur et automatisation de tâches

S’il n’est pas nécessaire d’utiliser de post-processeur ni de logiciel d’automatisation de tâches pour utiliser nos outils, certains de nos projets utilisent ce genre de procédés pour optimiser la contribution et il est possible que nous vous demandions de vous en servir pour contribuer à nos projets.

Post-processeur : Myth

Le post-processeur que nous utilisons est Myth. Pour contribuer au CSS il est indispensable de passer par cet outil, les sources étant ensuite compilées.

Toutes les infos sur Myth sur le site du projet.

Automatisation des tâches avec Grunt

Pour la compilation nous utilisons Grunt. Les projets contiennent le Gruntfile.js avec notre configuration.

Nous utilisons Grunt pour des besoins réduits. Notre configuration concerne : la compilation Myth, le regroupement des media-queries et la minification du CSS.

Pour les CSS nous effectuons 2 compilations : une minifiée et une non-minifiée, pour permettre à des intégrateurs qui n’utiliseraient ni Myth ni Grunt de pouvoir malgré tout modifier le code.

myth: {
 dist: {
   files: {
     'css/style.css':'css/sources/style.css',
     'css/themes/default.css':'css/sources/themes/default.css',
   }
 }
},

cmq: {
 dist: {
   files: {
     'css/style.css':'css/style.css',
     'css/themes/default.css':'css/themes/default.css',
   }
 },
},

cssmin: {
 dist: {
   files: {'css/style.min.css':'css/style.css',}
 },
 theme: {
   files: {'css/themes/default.min.css':'css/themes/default.css'}
 },
},

RWD

Nous privilégions, dans la mesure du possible, des déclarations mobile-first, ceci pour alléger le code CSS en sortie.

Dans les fichiers de développement, les media-queries sont déclarées aux endroits concernés, plutôt que de ne créer qu’une seule déclaration par point de rupture.

Lors de la compilation du CSS avec Grunt, les media-queries sont réunies, le CSS en sortie ne contient alors qu’une déclaration par point de rupture.

.main-header{
  position:relative;
  z-index:900;
  left:0;
}

@media (--medium){
  .main-header{
     margin:0 0 5px 0;
     padding:0 12%;
  }
}

Documentation

Pensez à commenter vos déclarations surtout lorsque les sélecteurs ne sont pas explicites. Nous utilisons la syntaxe CSSDoc. Découpez le code en grande partie :

/**
* @section 1. GENERIC STYLE
*/
[déclarations]

/**
* @section 2. MAIN LAYOUT
*/

/** @subsection 2.1 HEADER **/
[déclarations]