N'écrivez pas de titres en CSS
Il suffit de diviser les sections en fichiers. Tout commentaire CSS devrait être juste cela, des commentaires.
reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css
Utilisez un script pour les combiner en un seul; si nécessaire. Vous pouvez même avoir une belle structure de répertoires, et simplement faire en sorte que votre script recherche récursivement des .cssfichiers.
Si vous devez écrire des en-têtes, ayez une table des matières au début du fichier
Les titres de la table des matières doivent être parfaitement égaux aux titres que vous écrirez plus tard. C'est pénible de chercher des titres. Pour ajouter au problème, comment peut-on exactement savoir que vous avez un autre en-tête après votre premier en-tête? ps. N'ajoutez pas de doc-like * (étoile) au début de chaque ligne lors de l'écriture des tables des matières, cela rend simplement plus ennuyeux la sélection du texte.
/* Table of Contents
- - - - - - - - -
Header stuff
Body Stuff
Some other junk
- - - - - - - - -
*/
...
/* Header Stuff
*/
...
/* Body Stuff
*/
Écrire des commentaires avec ou dans les règles, pas en dehors du bloc
Tout d'abord, lorsque vous éditez le script, il y a 50% de chances que vous fassiez attention à ce qui est en dehors du bloc de règles (en particulier si c'est un gros globe de texte;)). Deuxièmement, il n'y a (presque) aucun cas où vous auriez besoin d'un "commentaire" à l'extérieur. S'il est à l'extérieur, c'est 99% du temps un titre, alors gardez-le comme ça.
Fractionner la page en composants
Les composants devraient avoir position:relative, non paddinget non margin, la plupart du temps. Cette Simplifie% des règles beaucoup, tout en permettant à beaucoup plus simple absolute:positioning » des éléments, car s'il y a un récipient positionné absolu l'élément positionné absolu utilisera le récipient lors du calcul top, right, bottom, leftpropriétés.
La plupart des DIV d'un document HTML5 sont généralement des composants.
Un composant est également quelque chose qui peut être considéré comme une unité indépendante sur la page. En termes simples, traiter quelque chose comme un composant s'il est logique de traiter quelque chose comme une boîte noire .
Reprenons l'exemple de la page QA:
#navigation
#question
#answers
#answers .answer
etc.
En divisant la page en composants, vous divisez votre travail en unités gérables.
Mettez les règles avec un effet cumulatif sur la même ligne.
Par exemple border, marginet padding(mais pas outline) tous ajoutent aux dimensions et à la taille de l'élément que vous dénommez.
position: absolute; top: 10px; right: 10px;
S'ils ne sont tout simplement pas lisibles sur une seule ligne, placez-les au moins à proximité:
padding: 10px; margin: 20px;
border: 1px solid black;
Utilisez un raccourci lorsque cela est possible:
/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;
Ne répétez jamais un sélecteur
Si vous avez plusieurs instances du même sélecteur, il y a de fortes chances que vous vous retrouviez inévitablement avec plusieurs instances des mêmes règles. Par exemple:
#some .selector {
margin: 0;
font-size: 11px;
}
...
#some .selector {
border: 1px solid #000;
margin: 0;
}
Évitez d'utiliser des TAG comme sélecteurs lorsque vous pouvez utiliser id / classes
Tout d'abord, les balises DIV et SPAN sont l'exception: vous ne devriez jamais les utiliser, jamais! ;) Utilisez-les uniquement pour attacher une classe / id.
Cette...
div#answers div.answer table.statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
outline: 3px solid #000;
}
Doit être écrit comme ceci:
#answers .answer .statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}
Parce que les DIV supplémentaires pendantes n'y ajoutent rien au sélecteur. Ils forcent également une règle de balise inutile. Si vous deviez changer, par exemple, .answerde a divà a, articlevotre style se briserait.
Ou si vous préférez plus de clarté:
#answers .answer .statistics {
color: pink;
border: 1px solid #000;
}
#answers .answer table.statistics {
border-collapse: collapsed;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}
La raison d'être de la border-collapsepropriété est une propriété spéciale qui n'a de sens que lorsqu'elle est appliquée à un table. Si ce .statisticsn'est pas tablele cas, cela ne devrait pas s'appliquer.
Les règles génériques sont mauvaises!
- évitez d'écrire des règles génériques / magiques si vous le pouvez
- à moins qu'il ne s'agisse d'une réinitialisation / réinitialisation CSS, toute votre magie générique devrait s'appliquer à au moins un composant racine
Ils ne vous font pas gagner de temps, ils font exploser votre tête; ainsi que faire de l'entretien un cauchemar. Lorsque vous rédigez la règle, vous savez peut-être où elle s'applique, mais cela ne garantit pas que votre règle ne vous dérangera pas plus tard.
Pour ajouter à cela, les règles génériques sont déroutantes et difficiles à lire, même si vous avez une idée du document que vous stylisez. Cela ne veut pas dire que vous ne devez pas écrire de règles génériques, ne les utilisez pas à moins que vous ne vouliez vraiment qu'elles soient génériques, et même qu'elles ajoutent autant d'informations de portée que possible dans le sélecteur.
Des trucs comme ça ...
.badges {
width: 100%;
white-space: nowrap;
}
address {
padding: 5px 10px;
border: 1px solid #ccc;
}
... a le même problème que l'utilisation de variables globales dans un langage de programmation. Vous devez leur donner de la place!
#question .userinfo .badges {
width: 100%;
white-space: nowrap;
}
#answers .answer .userinfo address {
padding: 5px 10px;
border: 1px solid #ccc;
}
Fondamentalement, cela se lit comme suit:
components target
---------------------------- --------
#answers .answer .userinfo address
-------- --------- --------- --------
domain component component selector
J'aime utiliser les ID chaque fois qu'un composant que je connais est un singleton sur une page; vos besoins peuvent être différents.
Remarque: Idéalement, vous devriez écrire juste assez. Cependant, mentionner plus de composants dans le sélecteur est l'erreur la plus tolérante par rapport à mentionner moins de composants.
Supposons que vous ayez un paginationcomposant. Vous l'utilisez à de nombreux endroits sur votre site. Ce serait un bon exemple du moment où vous écririez une règle générique. Permet de vous dire display:blockles liens des numéros de page individuels et de leur donner un fond gris foncé. Pour qu'ils soient visibles, vous devez avoir des règles comme celle-ci:
.pagination .pagelist a {
color: #fff;
}
Disons maintenant que vous utilisez votre pagination pour une liste de réponses, vous pouvez rencontrer quelque chose comme ça
#answers .header a {
color: #000;
}
...
.pagination .pagelist a {
color: #fff;
}
Cela rendra vos liens blancs noirs, ce que vous ne voulez pas.
La façon incorrecte de le réparer est:
.pagination .pagelist a {
color: #fff !important;
}
La bonne façon de le réparer est:
#answers .header .pagination .pagelist a {
color: #fff;
}
Les commentaires "logiques" complexes ne fonctionnent pas :)
Si vous écrivez quelque chose comme: "cette valeur dépend du bla-bla combiné à la hauteur du bla-bla", il est juste inévitable que vous fassiez une erreur et tout tombera comme un château de cartes.
Gardez vos commentaires simples; si vous avez besoin d '"opérations logiques", envisagez l'un de ces langages de modèles CSS comme SASS ou LESS .
Comment dois-je écrire une palette de couleurs?
Laissez cela pour la fin. Ayez un fichier pour toute votre palette de couleurs. Sans ce fichier, votre style devrait toujours avoir une palette de couleurs utilisable dans les règles. Votre palette de couleurs doit remplacer. Vous enchaînez les sélecteurs à l'aide d'un composant parent de très haut niveau (par exemple #page), puis écrivez votre style en tant que bloc de règles autosuffisant. Cela peut être simplement de la couleur ou quelque chose de plus.
par exemple.
#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
color: #222; background: #fff;
border-radius: 10px;
padding: 1em;
}
L'idée est simple, votre palette de couleurs est une feuille de style indépendante du style de base, dans laquelle vous cascadez .
Moins de noms, nécessite moins de mémoire, ce qui facilite la lecture du code
Il est préférable d'utiliser moins de noms. Idéalement, utilisez des mots très simples (et courts!): Texte, corps, en-tête.
Je trouve également que la combinaison de mots simples est plus facile à comprendre qu'avoir une soupe de longs mots "appropriés": postbody, posthead, userinfo, etc.
Gardez le vocabulaire petit, de cette façon, même si un étranger qui vient lire votre soupe de style (comme vous après quelques semaines;)) a seulement besoin de comprendre où les mots sont utilisés plutôt que où chaque sélecteur est utilisé. Par exemple, j'utilise .thischaque fois qu'un élément est censé être "l'élément sélectionné" ou "l'élément actuel", etc.
Nettoyez après vous
Écrire du CSS, c'est comme manger, parfois on laisse un désordre derrière. Assurez-vous de nettoyer ce gâchis, sinon le code de la poubelle s'accumulera. Supprimez les classes / identifiants que vous n'utilisez pas. Supprimez les règles CSS que vous n'utilisez pas. Assurez-vous que tout va bien et que vous n'avez pas de règles conflictuelles ou dupliquées.
Si vous, comme je l'ai suggéré, avez traité certains conteneurs comme des boîtes noires (composants) dans votre style, utilisé ces composants dans vos sélecteurs et conservé tout dans un fichier dédié (ou fractionné correctement un fichier avec une table des matières et des en-têtes), alors votre le travail est beaucoup plus facile ...
Vous pouvez utiliser un outil tel que l'extension firefox Dust-Me Selectors (astuce: pointez-le sur votre sitemap.xml) pour vous aider à trouver certaines des ordures cachées dans vos armes nucléaires et carnies.
Garder un unsorted.css dossier
Imaginons que vous stylisiez un site d'AQ et que vous ayez déjà une feuille de style pour la "page de réponses", que nous appellerons answers.css. Si vous devez maintenant ajouter beaucoup de nouveaux CSS, ajoutez-le à la unsorted.cssfeuille de style, puis refactorisez-le dans votre answers.cssfeuille de style.
Plusieurs raisons à cela:
- il est plus rapide de refactoriser une fois que vous avez terminé, puis de rechercher des règles (qui n'existent probablement pas) et d'injecter du code
- vous écrirez des choses que vous supprimerez, l'injection de code rendra plus difficile la suppression de ce code
- l'ajout au fichier d'origine entraîne facilement une duplication règle / sélecteur
simplicity,complexity,maintenance,structureetrefactoring.