Normes de codage CSS Bootstrap
Syntaxe
- Utilisez deux espaces au lieu de tabulations -- c'est le seul moyen de garantir un rendu cohérent dans tous les environnements.
- Lorsque vous regroupez des sélecteurs, placez chaque sélecteur individuel sur sa propre ligne.
- Pour une meilleure lisibilité, ajoutez un espace avant l'accolade ouvrante de chaque bloc de déclaration.
- L'accolade fermante d'un bloc de déclaration doit être sur sa propre ligne.
- Le deux-points de chaque instruction de déclaration
:doit être suivi d'un espace. - Pour un rapport d'erreurs plus précis, chaque déclaration doit être sur sa propre ligne.
- Toutes les instructions de déclaration doivent se terminer par un point-virgule. Le point-virgule après la dernière déclaration est facultatif, mais l'omettre peut rendre votre code plus sujet aux erreurs.
- Pour les valeurs de propriété séparées par des virgules, insérez un espace après chaque virgule (par exemple,
box-shadow)。 - N'utilisez pas
rgb()、rgba()、hsl()、hsla()ourect()dans la valeur d'unà l'intérieur deinsérez un espace après la virgule. Cela aide à distinguer plusieurs valeurs de couleur (virgules sans espaces) de plusieurs valeurs de propriété (virgules avec espaces). - Pour les valeurs de propriété ou les paramètres de couleur, omettez le 0 initial pour les décimales inférieures à 1 (par exemple,
.5au lieu de0.5;-.5pxau lieu de-0.5px)。 - Les valeurs hexadécimales doivent être en minuscules, par ex.,
#fffLors de la numérisation de documents, les caractères en minuscules sont plus faciles à distinguer car leurs formes sont plus distinctes. - Utilisez des valeurs hexadécimales abrégées lorsque c'est possible, par ex., utilisez
#fffau lieu de#ffffff。 - Ajoutez des guillemets doubles aux attributs dans les sélecteurs, par ex.,
input[type="text"]。Les guillemets sont facultatifs uniquement dans certains casCependant, pour des raisons de cohérence, il est recommandé de toujours utiliser des guillemets doubles. - Évitez de spécifier des unités pour les valeurs nulles, par ex., utilisez
margin: 0;au lieu demargin: 0px;。
Des questions sur la terminologie utilisée ici ? Voir la page de WikipédiaCascading Style Sheets - Syntax。
/* Bad CSS */
.selector, .selector-secondary, .selector[type=text] {
padding:15px;
margin:0px 0px 15px;
background-color:rgba(0, 0, 0, 0.5);
box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF
}
/* Good CSS */
.selector,
.selector-secondary,
.selector[type="text"] {
padding: 15px;
margin-bottom: 15px;
background-color: rgba(0,0,0,.5);
box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;
}
Ordre des déclarations
Les déclarations de propriétés liées doivent être regroupées et disposées dans l'ordre suivant :
- Positionnement
- Modèle de boîte
- Typographique
- Visuel
Le positionnement peut retirer des éléments du flux normal du document et peut remplacer les styles liés au modèle de boîte, c'est pourquoi il est placé en premier. Le modèle de boîte vient en second car il détermine la taille et la position d'un composant.
Les autres propriétés affectent uniquement l'intérieurdu composant ou n'affectent pas les deux premiers groupes, elles sont donc placées plus tard.
Pour la liste complète des propriétés et leur ordre, veuillez vous référer àRecess。
.declaration-order {
/* Positioning */
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
z-index: 100;
/* Box-model */
display: block;
float: right;
width: 100px;
height: 100px;
/* Typography */
font: normal 13px "Helvetica Neue", sans-serif;
line-height: 1.5;
color: #333;
text-align: center;
/* Visual */
background-color: #F5F5F5;
border: 1px solid #E5E5E5;
border-radius: 3px;
/* Misc */
opacity: 1;
}
Ne pas utiliser@import
et<link>Par rapport à la balise,@importles directives sont beaucoup plus lentes, non seulement en ajoutant des requêtes supplémentaires, mais aussi en causant des problèmes imprévisibles. Les alternatives incluent :
- Utiliser plusieurs
<link>éléments - Compiler plusieurs fichiers CSS en un seul fichier via un préprocesseur CSS tel que Sass ou Less.
- Grâce à la fonctionnalité de fusion de fichiers CSS fournie par Rails, Jekyll ou d'autres systèmes.
Veuillez consulterl'article de Steve Souderspour en savoir plus.
<!-- Use link elements -->
<link rel="stylesheet" href="core.css.html">
<!-- Avoid @imports -->
<style>
@import url("more.css");
</style>
Placement des requêtes média
Placez les requêtes média aussi près que possible des règles associées. Ne les regroupez pas dans une seule feuille de style et ne les placez pas en bas du document. Si vous les séparez, elles finiront par être oubliées. Un exemple typique est donné ci-dessous.
.element { ... }
.element-avatar { ... }
.element-selected { ... }
@media (min-width: 480px) {
.element { ...}
.element-avatar { ... }
.element-selected { ... }
}
Propriétés préfixées
Lorsque vous utilisez des propriétés avec préfixe vendeur, indentez afin que la valeur de chaque propriété soit alignée verticalement, ce qui facilite l'édition sur plusieurs lignes.
Dans Textmate, utilisezText → Edit Each Line in Selection(⌃⌘A). Dans Sublime Text 2, utilisezSelection → Add Previous Line(⌃⇧↑) etSelection → Add Next Line (⌃⇧↓).
/* Prefixed properties */
.selector {
-webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15);
box-shadow: 0 1px 2px rgba(0,0,0,.15);
}
Déclarations de règle sur une seule ligne
Pourles styles ne contenant qu'une seule déclaration, pour la lisibilité et l'édition rapide, il est recommandé de placer les instructions sur la même ligne. Pour les styles avec plusieurs déclarations, les déclarations doivent toujours être réparties sur plusieurs lignes.
Le facteur clé ici est la détection d'erreurs -- par exemple, un validateur CSS signale une erreur de syntaxe à la ligne 183. S'il s'agit d'une seule déclaration sur une ligne, vous ne passerez pas à côté de l'erreur ; s'il s'agit de plusieurs déclarations sur une ligne, vous devez analyser attentivement pour éviter de manquer des erreurs.
/* Single declarations on one line */
.span1 { width: 60px; }
.span2 { width: 140px; }
.span3 { width: 220px; }
/* Multiple declarations, one per line */
.sprite {
display: inline-block;
width: 16px;
height: 15px;
background-image: url(../img/sprite.png);
}
.icon { background-position: 0 0; }
.icon-home { background-position: 0 -20px; }
.icon-account { background-position: 0 -40px; }
Déclarations de propriétés raccourcies
Lorsque vous devez définir explicitement toutes les valeurs, vous devriez essayer de limiter l'utilisation des déclarations de propriétés raccourcies. Les cas courants d'abus de déclarations de propriétés raccourcies sont les suivants :
paddingmarginfontbackgroundborderborder-radius
Dans la plupart des cas, nous n'avons pas besoin de spécifier toutes les valeurs pour les déclarations de propriétés raccourcies. Par exemple, les éléments de titre HTML n'ont besoin de définir que les valeurs de marge supérieure et inférieure, donc lorsque c'est nécessaire, ne redéfinissez que ces deux valeurs. Une utilisation excessive des déclarations de propriétés raccourcies peut entraîner une confusion dans le code et des redéfinitions inutiles des valeurs de propriété, conduisant à des effets secondaires inattendus.
MDN (Mozilla Developer Network) propose un excellent article surles propriétés raccourcies, article qui est très utile pour les utilisateurs qui ne sont pas familiers avec les déclarations de propriétés raccourcies et leur comportement.
/* Bad example */
.element {
margin: 0 0 10px;
background: red;
background: url("image.jpg");
border-radius: 3px 3px 0 0;
}
/* Good example */
.element {
margin-bottom: 10px;
background-color: red;
background-image: url("image.jpg");
border-top-left-radius: 3px;
border-top-right-radius: 3px;
}
Imbrication dans Less et Sass
Évitez l'imbrication inutile. En effet, bien que vous puissiez utiliser l'imbrication, cela ne signifie pas que vous devez le faire. N'utilisez l'imbrication que lorsque vous devez restreindre les styles à un élément parent (c'est-à-dire des sélecteurs descendants) et que plusieurs éléments ont besoin d'être imbriqués.
// Without nesting
.table > thead > tr > th { … }
.table > thead > tr > td { … }
// With nesting
.table > thead > tr {
> th { … }
> td { … }
}
Commentaires
Le code est écrit et maintenu par des personnes. Veillez à ce que votre code soit auto-descriptif, bien commenté et facile à comprendre pour les autres. De bons commentaires de code transmettent le contexte et l'objectif. Ne vous contentez pas de répéter les noms de composants ou de classes.
Pour les commentaires plus longs, veillez à écrire des phrases complètes ; pour les annotations générales, des phrases concises sont acceptables.
/* Bad example */
/* Modal header */
.modal-header {
...
}
/* Good example */
/* Wrapping element for .modal-title and .modal-close */
.modal-header {
...
}
Nommage des classes
- Les noms de classes ne doivent contenir que des caractères minuscules et des tirets (pas de traits de soulignement, pas de camelCase). Les tirets doivent être utilisés pour nommer des classes liées (similaire aux espaces de noms) (par ex.,
.btnet.btn-danger)。 - Évitez les abréviations trop arbitraires.
.btnreprésentebutton, mais.sne transmet aucun sens. - Les noms de classes doivent être aussi courts que possible et clairement significatifs.
- Utilisez des noms significatifs. Utilisez des noms organisés ou orientés vers un objectif, et non des noms liés à la présentation.
- Utilisez la classe parente la plus proche ou la classe de base comme préfixe pour les nouvelles classes.
- Utiliser
.js-*classes pour identifier le comportement (par opposition aux styles), et n'incluez pas ces classes dans les fichiers CSS.
Vous pouvez également vous référer aux spécifications listées ci-dessus lors du nommage des variables Sass et Less.
/* Bad example */
.t { ... }
.red { ... }
.header { ... }
/* Good example */
.tweet { ... }
.important { ... }
.tweet-header { ... }
Sélecteurs
- Utilisez des classes pour les éléments génériques, ce qui est bénéfique pour l'optimisation des performances de rendu.
- Pour les composants fréquents, évitez les sélecteurs d'attribut (par ex.,
[class^="..."]). Les performances du navigateur sont affectées par ces facteurs. - Les sélecteurs doivent être aussi courts que possible, et essayez de limiter le nombre d'éléments composant un sélecteur ; il est recommandé de ne pas dépasser 3.
- Uniquementlorsque c'est nécessaire, vous devriez restreindre la classe à l'élément parent le plus proche (c'est-à-dire les sélecteurs descendants) (par ex., lorsque vous n'utilisez pas de classes préfixées -- le préfixe est similaire à un espace de noms).
Pour aller plus loin :
/* Bad example */
span { ... }
.page-container #stream .stream-item .tweet .tweet-header .username { ... }
.avatar { ... }
/* Good example */
.avatar { ... }
.tweet-header .username { ... }
.tweet .avatar { ... }
Organisation du code
- Organiser les segments de code par composant.
- Établir des conventions de commentaires cohérentes.
- Utiliser des espaces blancs cohérents pour séparer le code en blocs, ce qui facilite le parcours de longs documents.
- Si vous utilisez plusieurs fichiers CSS, répartissez-les par composant plutôt que par page, car les pages peuvent être réorganisées, tandis que les composants sont seulement déplacés.
/*
* Component section heading
*/
.element { ... }
/*
* Component section heading
*
* Sometimes you need to include optional context for the entire component. Do that up here if it's important enough.
*/
.element { ... }
/* Contextual sub-component or modifer */
.element-heading { ... }
Configuration de l'éditeur
Configurez votre éditeur comme suit pour éviter les incohérences de code courantes et les diffs :
- Utilisez deux espaces au lieu de tabulations (tabulation douce, c'est-à-dire des espaces au lieu de caractères de tabulation).
- Lors de l'enregistrement des fichiers, supprimez les espaces blancs de fin de ligne.
- Définissez l'encodage des fichiers sur UTF-8.
- Ajoutez une ligne vide à la fin du fichier.
Reportez-vous à la documentation et ajoutez ces paramètres de configuration au.editorconfigfichier du projet. Par exemple :L'exemple .editorconfig dans Bootstrap. Pour plus d'informations, reportez-vous àà propos d'EditorConfig。