BCW-3 Recommandations le codage des feuilles de style

Introduction

Les feuilles de style CSS sont principalement constituées de règles de style. Chaque règle comporte un sélecteur ou une liste de sélecteurs 1, suivi d’une liste de déclarations (p.ex. 2). Chaque déclaration est constituée d’une propriété 3 suivie d’une valeur 4, laquelle peut avoir plusieurs composantes 5. Certaines propriétés peuvent admettre des déclarations comportant une liste de valeurs 6. 

h1,
h2 {
	margin: 0 auto;
	color: green;
	border: 1px solid black;
	font-family: Arial, Helvetica, sans-serif;
}

Un sélecteur CSS est constitué de sélecteurs simples qui peuvent être juxtaposé en sélecteurs composites, lesquels peuvent se combiner grâce à des combinateurs (définitions de [CSS3] et [CSS4]). Quand il y a combinaison, on parle de sélecteurs complexes.

Un sélecteur simple est : un sélecteur universel (*), un sélecteur de balise ou type (p. ex. nav), un sélecteur de pseudo-classe (p. ex. :valid), un sélecteur d’attribut (p. ex. a[href]), un sélecteur de classe (p. ex. .nouvelles) ou un sélecteur d’identifiant (p. ex. #contact).

Mise en forme des règles

Version : 1.0.2, date : , permalink : https://yannisdelmas.github.io/beau-code-web/guide-style.html#forme

  1. Dans une liste de sélecteurs, il est recommandé de ne mettre qu’un sélecteur par ligne.
  2. De même, il est recommandé de ne mettre qu’une déclaration par ligne.
  3. Chaque déclaration doit se terminer par un point-virgule ;, même quand celui-ci est facultatif.
  4. Les espacements doivent être utilisés de façon cohérente sur l’ensemble d’un site.
  5. Il est recommandé de ne pas mettre d’espace entre une propriété et le séparateur :, mais d’en mettre un systématiquement après ce séparateur. De même, il est recommandé de mettre un espace après chaque virgule , dans une liste de valeurs, mais pas devant. Il est également recommandé de faire précéder les accolades ouvrantes { d’un espace.
Justification
  1. La même logique préside aux trois premiers points : un changement doit pouvoir être localisé sur une ou plusieurs lignes, mais pas au sein d’une ligne. La principale raison est la maintenabilité. Ceci permet aux systèmes de versionnement, Git ou autre, de suivre individuellement chaque modification, limitant ainsi les risques de conflits au moment des fusions merge. Accessoirement, cela permet aussi de faire des tests en commentant plus aisément tel ou telle déclaration. En effet, à titre de contre-exemple, si l’on plaçait des déclarations de position, top, left et right sur une même ligne, il ne serait pas facile d’agir sur la seule déclaration de top.
  2. La raison la plus souvent invoquée pour la règle précédente, « un changement par ligne », est la lisibilité, mais il semble que celle-ci dépende surtout des habitudes de chaque codeur. C’est donc la principale raison du point n°4.
  3. Le point n°5 est également motivé par des raisons de lisibilité. Les espaces recommandés permettent une séparation visuelle suffisante. L’absence d’espace devant les séparateurs permet de respecter la typographie de l’anglais, langue de référence du CSS, et donc d’assurer une meilleure cohérence à un niveau international.

Ordre des déclarations dans une règle

Version : 1.0.1, date : , permalink : https://yannisdelmas.github.io/beau-code-web/guide-style.html#ordre

  1. Si le sens d’une propriété A dépend de la valeur d’une propriété B, alors A devrait apparaître après B.

  2. Les propriétés devraient être groupées en blocs cohérents. Pour plus de lisibilité certains blocs ou sous-blocs peuvent être séparés par des lignes vides. Entre les blocs et, éventuellement, au sein d’un bloc, la règle précédente s’applique.

Justification

  1. Découle de l’objectif de lisibilité. Sans cela, pour une compréhension correcte de la règle CSS, un lecteur devrait soit faire des aller-retours parmi les déclarations, soit conserver en mémoire l’ensemble de la règle avant de pouvoir l’interpréter. Suivre l’ordre de dépendance permet donc de réduire la charge mentale des codeurs et les risques d’erreur d’interprétation.

  2. Il s’agit ici aussi de lisibilité. Le fait de grouper les déclarations par ensembles cohérents permet à un lecteur d’interpréter chacun puis de passer à la suite. Plus on est régulier dans l’application des règles d’ordre, plus il sera aisé de trouver une propriété particulière d’un simple coup d’œil.

Choisir ses sélecteurs CSS

Version : 1.0.1, date : , permalink : https://yannisdelmas.github.io/beau-code-web/guide-style.html#selecteurs

Les règles suivantes s’appliquent à la rédaction des sélecteurs, par ordre décroissant d’importance et sous réserve du niveau de compatibilité recherché.

Dans ces règles, la négation d’une balise (:not(article)) est assimilée à une balise, la négation d’une pseudo-classe (:not(:lang(fr))) à une pseudo-classe et la négation d’une classe ou d’un attribut (:not(.dense)) à une classe ou un attribut, respectivement.

  1. Un sélecteur devrait désigner ses cibles le plus haut possible dans l’arborescence de la page.

  2. Quand des éléments peuvent être définis par un type, une balise, il est recommandé de préférer cette solution aux solutions suivantes ou à tout autre.

  3. Quand des éléments peuvent être définis par une pseudo-classe décrivant un état ou une propriété, il est recommandé de préférer cette solution aux solutions suivantes ou à tout autre.

    À l’exception de :root, cette règle ne concerne pas les pseudo-classes dites structurelles qui indiquent un emplacement dans l’arborescence du document.

  4. Quand un élément peut être défini par des attributs ou classes déjà existants pour sa sémantique, son fonctionnement ou son accessibilité, il est recommandé de préférer cette solution aux solutions suivantes ou à tout autre.

    C’est recommandé, de même, quand de tels attributs pourraient être ajoutés sans difficulté particulière.

    Les attributs personnalisés (data-…) doivent permettre une conversion bidirectionnelle avec le JavaScript. Il est recommandé, pour cela, de les écrire en kebab-case.

  5. Quand les règles précédentes ne s’appliquent pas, on peut désigner un élément à l’aide d’une classe personnalisées. Le choix d’un nom de classe devrait se limiter aux cas suivants.

    • Sémantique : décrit le rôle que peut occuper dans le texte le contenu des éléments cibles.
    • Fonction : décrit le rôle que les éléments cibles peuvent jouer dans une page, une interface ou un composant.
    • État : pour désigner l’état d’un élément.

  6. Le nom des identifiants, des classes et des attributs personnalisés doit être défini et utilisé de façon sensible à la casse (différence minuscules/majuscules).

Justification

  1. Ceci permet de gagner en généricité, d’où une meilleure maintenabilité. Cette règle réduit le plus souvent le nombre de cibles, d’où une meilleure performance.

  2. Maintenabilité : la spécificité est ainsi plus faible.

    Lisibilité : les balises sont un vocabulaire commun à tous les sites ; leur sémantique ne nécessite pas de connaître des choix particuliers à tel ou tel site.

  3. Lisibilité : comme pour la règle précédente, les pseudo-classes sont un vocabulaire commun à tous les sites ; leur sémantique ne nécessite pas de connaître des choix particuliers à tel ou tel site.

    En revanche, pour cette règle, on ne retient pas les pseudo-classes de structure autres que :root, :empty et :lang(), dans la mesure où elles dépendent d’une structure HTML plus susceptible de changer, ce qui pourrait poser des problèmes de maintenabilité.

  4. Ici, il s’agit d’améliorer la cohérence et, plus généralement, la lisibilité : on évite de créer inutilement de nouvelles désignations.

    Respect des standards : un attribut personnalisé s’écrit data-…, avec au moins un caractère après le tiret, est compatible avec le XML et ne comporte aucune majuscule latine (ASCII).

    L’écriture en kebab-case est un moyen simple de garantir une conversion univoque réversible en camelCase pour l’utilisation en JavaScript.

  5. Respect des standards : Les règles CSS doivent permettre d’assurer une traduction visuelle d’informations que les éléments et pseudo-éléments ciblés doivent pouvoir transmettre à l’utilisateur. Il s’agit ici de respecter la règle de division du travail entre le HTML et le CSS [HTMLDP, §3.4].

  6. Par défaut, la syntaxe du CSS est insensible à la casse, mais les identifiants sont sensibles à la casse (#id, .classe) La sensitivité à la casse des types et attributs dépend du langage. Cette règle assure la cohérence en se limitant au plus petit dénominateur commun.