Catégorisation de "bonnes pratiques (BPs) de codage" spécifiques à CSS

0. Exemples de BPs générales (pour CSS) relatives à certains critères de qualité

0.1. Exemples de BPs générales relatives au critère de complétude [completeness]

0.1.1. Plus de BPs (non conflictuelles) sont suivies, le mieux

Écrivez du code CSS générique et organisé (et donc évitez toute forme de redondance). E.g. :

• voir ces exemples de règles générales pour CSS ;
• utilisez des règles CSS basés sur l'usage de "flex" plutôt que "float".

On peut toutefois noter que la notion selon laquelle utiliser les éléments "strong" et "em" serait mieux que d'utiliser les éléments "b" et "i", parce que les deux derniers n'ont pas de sens sémantique, est idéologique plutôt que concrète. En effet,

• des particularités (et donc différences) sémantiques sont en fait attribuées à chacun de ces éléments (cf. 1 et 2), e.g. "strong" est pour du texte "important" alors que "b" serait pour mettre en valeur du texte pas aussi important ;
• la présentation pour "strong" (versus. "em") est par défaut la même que celle pour "b" (versus. "i"), tout concepteur de pages Web peut changer ces présentations par défaut, et s'il le fait pour des pages Web usuelles (→ pas des pages qu'il a écrites, coécrites, ...), il ne serait alors pas avantageux de donner des présentations différentes à "strong" (versus. "em") et "b" (versus. "i"). Bien-sûr, pour ses propres pages, quelqu'un peut décider de donner des sémantiques/présentations particulières et différentes à "strong" (versus. "em") et "b" (versus. "i") ; dans ce cas, le choix d'utiliser un de ces éléments se fait basé sur ces sémantiques/présentations particulières, pas parce qu'il serait "mieux" de le faire.

0.1.2. Restreindre aussi peu que possible

E.g. :

• Ne pas forcer une (seule) présentation particulière pour votre page Web : permettez à votre utilisateur (ou à son environnement) de choisir/changer un maximum de paramètres. Voir les recommandations générales à ce sujet. E.g., en CSS, évitez
  • les positionnements/tailles absolu(e)s : usage de "px", "em", ..., "absolute" ;
  • les fontes avec l'attribut "vw" (qui certes s'agrandissent avec la taille de l'écran mais) que l'utilisateur ne peut agrandir.
  • tout ce qui est spécifique à Windows ; il peut toutefois arriver que vous deviez utiliser des commentaires conditionnels pour que votre page s'affiche correctement sur Internet Explorer.
• Dans une feuille de style CSS, créer des règles CSS sur des classes plutôt que sur des IDs (→ éviter les règles CSS du genre "#... { ... }"), lorsque cela est pertinent. En effet :
  • Si l'auteur d'un fichier veut associer une règle CSS particulière à un élément particulier d'un seul fichier (i.e., pas un élément particulier réutilisé dans d'autres fichiers, e.g., un logo particulier), autant qu'il l'associe directement à l'élément via un attribut "style", cela évitera à l'auteur et à d'autres codeurs d'inutiles recherches et ajouts/lectures dans un fichier CSS séparé et simplifiera ainsi la compréhension de la présentation de l'élément en question en même temps que celle du fichier séparé s'il existe encore. Utiliser un fichier séparé ne facilite même pas un hypothétique usage d'une autre présentation pour cet élément par un autre personne : le travail à effectuer par cette personne pour arriver à cela est comparable.
  • Si l'auteur de fichiers veut associer une règle CSS particulière à un élément particulier réutilisé dans plusieurs de ces fichiers (e.g., un logo particulier), il peut tout aussi bien rendre explicite l'information "et élément et sa présentation sont partagées par plusieurs fichiers" en associant une classe à cet élément et créant une règle CSS pour cette classe plutôt que pour un ID. Certes, cette classe ne sera utilisée qu'une seule fois au maximum dans ces fichiers mais c'est le cas usuel pour de nombreuses classes, e.g. "header", "footer", "main", "nav", "h1", etc. Ces classes ne sont pas par nature des "classes singleton" puisqu'elles peuvent avoir plusieurs instances, une par fichier (parmi ceux cités plus haut, créés par le même auteur).
    Pour ce cas précis, de nombreuses entreprises ont choisi la convention d'utiliser un ID plutôt qu'une classe. La documentation du W3C ne préconise rien à ce sujet, comme elle ne préconise rien sur comment choisir entre différentes méthodologies ou conventions de règles de nommage (cf. section 2.1.1). Pour le cours "Projet HTML", afin de simplifier, le choix à suivre est d'utiliser une classe pour ce cas aussi (mais ce cas ne devrait pas arriver puisque chaque étudiant ne soumet qu'un seul document HTML).
  • Les étudiants n'ont que trop tendance à créer des règles CSS pour des IDs alors que, dans la majorité des cas, associer ces règles à des classes rendrait une feuille de style nettement plus générique et donc nettement plus utile ou réutilisable.
• Si une règle CSS est pour une classe d'éléments et qu'elle n'est – "à juste titre" (cf. ci-dessous) – utilisée que dans un seul fichier, vous pouvez la mettre dans l'entête du fichier HTML : il n'y a pas de raison d'avoir à la rechercher dans un autre fichier (ni donc, éventuellement, à créer cet autre fichier et avoir à gérer ses versions). Le précédent "à juste titre" veut dire que généraliser la règle pour pouvoir l'utiliser dans d'autres fichiers aurait plus d'inconvénients que d'avantages.
  Le titre de la section 2.4.1.4 dans le document catégorisant des BPs de codage générales mentionne, à titre d'exemple, l'utilisation (dans un éditeur de texte) d'une vue pour du code HTML et d'une vue pour du code CSS. Lorsque les règles CSS "liées à des classes" sont dans l'entête d'un fichier HTML plutôt que dans un fichier séparé, et que seul ce fichier est édité, les deux vues montrent des parties différentes de ce fichier.
• Mieux vaut 1 feuille de style pour un "mode adaptatif" (→ générique → longue/complexe) que plusieurs feuilles de style différentes (1 pour chaque type de public supposé ; cet autre mode est souvent nommé le "mode réactif" [Responsive Web Design (RWD)] ; W3schools n'introduit que ce mode réactif [responsif] ou ne fait pas la différence entre les 2 modes).
  Mais, bien-sûr, en l'absence d'un mode adaptatif, mieux vaut plusieurs feuilles de style (1 par "type de public" considéré -> mode réactif) qu'aucun de ces deux modes.
  Donc, pour le cours "Projet HTML", il faut utiliser au moins l'un de ces deux modes et, autant que possible, tendre vers un mode adaptatif, progressivement ou non ; l'approche progressive est souvent appelée "adaptive responsive". Attention, en anglais, "reactive" désigne parfois aussi une combinaison de "adaptive" et "responsive".

0.1.3. Représenter de manière aussi complète, précise et structurée que possible

Par exemple, pour faciliter la compréhension et les recherches manuelles d'informations dans une feuille de style, il est utile

• de distinguer ses sous-parties (en utilisant différents fichiers ou des espaces et des commentaires, puisque CSS n'offre guère d'autres moyens de structuration), typiquement en
  • ne sautant pas de lignes dans un paquet de règles travaillant sur un même type d'élément (e.g., les ancres), ou sur les parties d'un même type d'élément (e.g., les parties d'une table), ou pour une même fonctionnalité (e.g., pour un même type de menu) ;
  • en sautant des lignes entre les paquets de règles ;
  • en indiquant la structure au moyen de titres de sections dans des commentaires, comme indiqué dans la section 0.2.1.3 du fichier sur les BPs générales ;
• d'ordonner les (paquets de) règles en suivant la relation d'inclusion/spécialisation entre les éléments sur lesquels portent les règles, typiquement: root, puis document, puis les éléments "blocs" (par défaut), puis les éléments "inline", puis les classes définies par les utilisateurs, puis les éléments individuels, puis les règles pour un média particulier.

1. BPs relatives aux objets abstraits "informationnels" (i.e., tous les objets abstraits sauf ceux pour des présentations)

Dans ce fichier pour CSS, contrairement à celui pour HTML, cette section et sous-section ne sont pour l'instant pas utiles : l'instanciation (pour les objets abstraits informationnels en CSS) des BPs générales sont simples et cette instanciation est déjà illustrée dans la précédente section. Cette présente section est donc essentiellement conservée pour des raisons de structure et de symétrie par rapport aux autres fichiers (le général et celui pour HTML).

L'entête d'un fichier CSS contient à peu près les mêmes informations minimum que l'entête d'un fichier HTML. Un (entête d'un) fichier modèle pour CSS est ici donnée.

2. BPs relatives aux instruments de description

2.1. BPs à propos d'identifiants (d'objets de codage)

2.1.1. Utiliser des règles de nommage compatibles avec les règles générales données mais, CSS n'étant pas sensible à la casse, les noms des éléments HTML peuvent être mis en majuscules

Il existe différentes conventions de nommage (et modélisation) pour CSS, e.g. BEM [Block__Element--Modifier], SMACSS [Scalable and Modular Architecture for CSS], ACSS [Atomic CSS] et OOCSS [Object-oriented CSS]. Utilisez celle que vous souhaitez mais de manière systématique.

Comme illustré en section 3.1.2, les noms des éléments HTML peuvent être mis en majuscules pour rendre le code plus clair.

2.1.2. Référez aux couleurs via leurs noms plutôt que par des valeurs numériques

Les navigateurs modernes supportent 140 noms de couleurs différentes (voir aussi cette liste).
Vous avez donc la possibilité d'utiliser des noms de couleurs plutôt que des valeurs numériques, e.g., "LightSalmon" au lieu de "#FFA07A" ou "RGB(255,160,122)". Utilisez cette possibilité pour éviter au lecteur de votre code de se demander à quelles couleurs vous référez.
Si ces 140 couleurs ne suffisent pas, il est aussi possible

• de créer une classe CSS définissant une certaine couleur (e.g., de fond ou de texte) en utilisant une valeur numérique, et de nommer la classe en référant à cette couleur (e.g. "backgroundInVeryLightSalmonColor"), et ensuite
• d'utiliser cette classe (et donc un nom référant à une couleur) au lieu d'une valeur numérique.

2.2. BPs à propos de l'utilisation d'un langage naturel

Section vide conservée pour des raisons de structure et de symétrie par rapport aux autres fichiers (le général et celui pour HTML).

2.3. BPs à propos de l'utilisation d'un langage de codage

2.3.1. Utiliser au moins un validateur pour ce langage, avec ses options les plus strictes

Le validateur du W3C pour la syntaxe CSS est à utiliser sur tout fichier CSS dans le cours "Projet HTML".

3. BPs relatives aux aspects concrets ou de présentation (de code ou de résultats de son exécution)

3.1. BPs pour des éléments concrets concis/compacts

3.1.1. Limiter le nombre de caractères par ligne de code (→ pour vous, 89)

L'entête de ce modèle pour des fichiers CSS comprend une ligne de 89 caractères contenant essentiellement des '='. Il suffit donc d'ajuster la largeur de fenêtre de l'éditeur de texte par rapport à cette ligne de commentaire pour que l'éditeur fasse apparaître un "passage à la ligne" [soft line wrapping] (ou ne montre plus l'entièreté d'une ligne ; cela s'accompagne souvent de l'apparition d'un ascenseur horizontal), à chaque fois que la limite n'est pas respectée.

3.1.2. Pas de lignes vides sauf pour séparer des blocs élémentaires ; mettre plusieurs instructions par ligne lorsqu'il y a suffisamment de place pour cela

Il vaut mieux éviter de sauter des lignes à l'intérieur d'un bloc élémentaire, et remplir chaque ligne, non seulement pour avoir les avantages d'un style compact (voir le début de la section 3.1 du fichier général) mais aussi pour bien voir les blocs (lorsqu'il n'y a pas d'autres marques pour les délimiter) et pouvoir présenter les informations d'une manière compacte – voire même tabulaire – qui facilite la comparaison de ces informations et ainsi leur compréhension globale (→ compréhension de leurs inter-relations, interactions, etc.). Ceci est illustré par chacune des deux sous-sections suivantes. La première illustre l'avantage d'une présentation compacte et tabulaire par rapport à une présentation non compacte. Comme il est toutefois rare de pouvoir utiliser une présentation tabulaire, la seconde sous-section montre, pour un cas général, l'avantage d'une présentation compacte par rapport à une présentation non compacte.

3.1.2.1. Présentation tabulaire versus présentation non compacte

Voici ci-dessous, une illustration de cela pour des règles CSS concernant des titres de sections puis des éléments HTML relatifs à du code (ou autre texte à présenter dans une fonte "monospace"). Concernant les titres de section, la classe "smallTopMargin" est utilisée pour avoir moins d'espaces entre les sections (→ pour des fichiers de taille moyenne, comme dans ce fichier), et la classe "first" est utilisée pour avoir encore moins d'espace entre un titre d'une section et un titre d'une sous-section qui le suit immédiatement (donc un titre de 1ère sous-section). Dans cette présentation tabulaire, ce sont d'abord les noms de classe qui sont alignés (comme dans une colonne d'une table ; l'alignement des noms d'attribut à l'intérieur de la colonne s'ensuit).

H1{        font-size:19pt;   counter-reset:h2n; margin-top:30%}
                                                                  H1.first{ margin-top:6% }
                           H1.smallTopMargin{   margin-top:20%}   H1.smallTopMargin.first{ margin-top:5% }
  H1.title{font-size:17pt; margin-left:7%;      margin-top: 0%}
H2{        font-size:16.5pt; counter-reset:h3n; margin-top:20%} 
                                                                  H2.first{ margin-top:5% }
                           H2.smallTopMargin{   margin-top:12%}   H2.smallTopMargin.first{ margin-top:4% } 
H3{        font-size:14.5pt; counter-reset:h4n; margin-top:10%}
                                                                  H3.first{ margin-top:4%                }
                           H3.smallTopMargin{   margin-top: 8%}   H3.smallTopMargin.first{ margin-top:3% } 
H4{        font-size:12.5pt; counter-reset:h5n; margin-top: 6%}   H4.first{ margin-top:3%                }
                           H4.smallTopMargin{   margin-top: 5%}   H4.smallTopMargin.first{ margin-top:2% } 
H5{        font-size:11pt;   counter-reset:h6n; margin-top: 3%}   H5.first{ margin-top:2%                }
                           H5.smallTopMargin{   margin-top: 3%}   H5.smallTopMargin.first{ margin-top:1% } 
                           H5.smallTopMargin{ margin-bottom:0%} 
H1,H2,H3,H4,H5,H6{ white-space: pre }

CODE    { font-family:monospace;  font-size:97% }
PRE, XMP{ margin-top:0%;          font-size:97% }
.pre-ed, pre{ white-space:pre }   .nowrap { white-space:nowrap } 

Voici ci-dessous une version non compacte des règles précédentes. Au moins dans ce cours, cette présentation non concise est à éviter pour les saisons suivantes.

• Cette présentation rend beaucoup plus difficile la comparaison du contenu des règles et donc la compréhension de leurs inter-relations, interactions, etc.
• Cette présentation peut faire croire à un grand nombre de règles alors qu'il y en a assez peu.
• La plupart des étudiants ne sont pas habitués à utiliser des présentations non compactes (e.g., parce que Python n'incite pas à cela). Ils ont donc une certaine réticence à "s'y plonger" (→ à les lire) et du mal à comprendre leurs avantages ou, en d'autres termes, la constante nécessité de comparaisons très rapides de données/codes/informations en programmation (d'où l'analogie avec le jeu des erreurs/différences au début de la section 2.4.1.3 du fichier général). Cette compréhension vient avec la pratique (et d'autant plus que les programmes lus/écrits sont gros ou complexes). Il faut aussi rappeler que 40% à 80% du temps passé sur un code est lié à sa maintenance/évolution, donc à la compréhension des interactions entre différentes parties du code, donc à des activités de comparaison.
• L'enseignant principal du cours "Projet HTML" n'a pas une mémoire photographique (comme en fait la plupart des étudiants et de leurs futurs chefs de projets et collaborateurs puisque avoir une mémoire photographique est très rare, en particulier à l'âge adulte, même si les études existantes – ou même les définitions – là-dessus ne concordent pas). Donc, pour les raisons évoquées ci-dessus, afin d'évaluer les codes des étudiants – ou afin de trouver rapidement l'origine de problèmes dans leurs codes – cet enseignant a besoin que ces codes soient compacts, et des futurs collaborateurs ou chefs de projets de ces étudiants en auront aussi besoin. Même si à moyen ou long terme, et pas dans toutes les situations, une solution à ce précédent besoin pourra être l'usage d'un "compacteur de code" automatique prenant en compte différents critères donnés par le lecteur du code, cela n'enlèvera pas la nécessité pour les étudiants de pratiquer l'écriture de codes compacts afin d'en comprendre les avantages.

H1 
{ font-size:19pt; 
  counter-reset:h2n;
  margin-top:30%;
}

H1.first
{ margin-top:6%;
}

H1.smallTopMargin 
{ margin-top:20%;
}

H1.smallTopMargin.first
{ margin-top:5%;
}

H1.title
{ font-size:17pt;
  margin-left:7%; 
  margin-top: 0%;
}

H2
{ font-size:16.5pt;
  counter-reset:h3n;
  margin-top:20%;
}

H2.first
{ margin-top:5%; }

H2.smallTopMargin
{ margin-top:12%; } 

H2.smallTopMargin.first
{ margin-top:4%; } 

H3
{ font-size:14.5pt;
  counter-reset:h4n;
  margin-top:10%;
}

H3.first
{ margin-top:4%;
}

H3.smallTopMargin
{  margin-top: 8%;
}

H3.smallTopMargin.first
{ margin-top:3%;
}
 
H4
{ font-size:12.5pt;
  counter-reset:h5n;
  margin-top: 6%;
}

H4.first
{ margin-top:3%;
}

H4.smallTopMargin 
{ margin-top: 5%;
}

H4.smallTopMargin.first
{ margin-top:2%;
}

H5
{ font-size:11pt;
  counter-reset:h6n;
  margin-top: 3%;
}

H5.first
{ margin-top:2%;
}

H5.smallTopMargin
{ margin-top: 3%;
}

H5.smallTopMargin.first
{ margin-top:1%;
}

H5.smallTopMargin
{ margin-bottom:0%;
}

H1, H2, H3, H4, H5, H6
{ white-space: pre;
}

CODE
{ font-family:monospace;
  font-size:97%;
}

PRE, XMP
{ margin-top:0%;
  font-size:97%;
}

.pre-ed, pre
{ white-space:pre
}

.nowrap
{ white-space:nowrap
}

3.1.2.2. Cas général pour une présentation compacte versus non compacte

Présentation compacte (→ modèle à suivre). Notez que

• pour cet exemple, il est supposé que 5 paires d'attribut-valeur tiennent dans les 89 caractères autorisés par ligne ;
• si cela est possible, il peut être intéressant d'aligner des noms d'attribut identiques, comme illustré ci-dessous, mais ceci étant rarement possible, il ne faut pas passer trop de temps à essayer d'obtenir cela ;
• il est bien plus important de bien grouper les règles de même nature – par exemple, tout ce qui est lié à des entêtes ou bien à des paragraphes, ou bien à des menus, etc. – et de bien séparer ces groupes par des lignes blanches, e.g. 3 lignes blanches pour des gros groupes et 1 ligne blanche pour des sous-groupes ;
• à l'intérieur d'une règle, il faut aussi essayer de grouper les attributs similaires (e.g., les attributs pour les marges, ou bien pour les fontes, ou bien ...), en les mettant sur une même ligne ou près les uns des autres.

H1
{ attributeName1:value1;  attributeName2:value2; ... ; attributeName5:value5;
  attributeName6:value6;  attributeName7:value7; ... ; attributeName10:value10
}
H2
{ attributeName1:value1;  attributeName7:value7;       attributeName5:value5;
  attributeName8:value8
}

Présentation non compacte (→ anti-modèle).

H1
{ attributeName1: value1; 
  ...
  attributeName10: value10;
}
H2
{ attributeName1: value1;  
  attributeName5: value5;
  attributeName7: value7;
  attributeName8: value8;  
}