Gérer l'explosion CSS

Je me suis beaucoup appuyé sur CSS pour un site Web sur lequel je travaille. À l'heure actuelle, tous les styles CSS sont appliqués sur une base par balise, et maintenant j'essaie de le déplacer vers plus d'un style externe pour aider à toute modification future.

Mais maintenant, le problème est que j'ai remarqué que j'obtiens une "explosion CSS". Il devient difficile pour moi de décider comment organiser et résumer au mieux les données dans le fichier CSS.

J'utilise un grand nombre de divbalises dans le site Web, passant d'un site Web fortement basé sur des tables. Je reçois donc beaucoup de sélecteurs CSS qui ressemblent à ceci:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

Ce n'est pas encore trop mal, mais comme je suis un débutant, je me demandais si des recommandations pouvaient être faites sur la meilleure façon d'organiser les différentes parties d'un fichier CSS. Je ne veux pas avoir d'attribut CSS séparé pour chaque élément de mon site Web, et je veux toujours que le fichier CSS soit assez intuitif et facile à lire.

Mon objectif ultime est de faciliter l'utilisation des fichiers CSS et de démontrer leur capacité à augmenter la vitesse de développement Web. De cette façon, d'autres personnes qui pourraient travailler sur ce site à l'avenir se familiariseront également avec de bonnes pratiques de codage, plutôt que de devoir les reprendre comme je l'ai fait.

C'est une très bonne question. Partout où je regarde, les fichiers CSS ont tendance à devenir incontrôlables après un certain temps, surtout, mais pas seulement, lorsque je travaille en équipe.

Voici les règles auxquelles j'essaie moi-même d'adhérer (pas que j'arrive toujours à.)

• Refactorisez tôt, refactorez souvent. Nettoyez fréquemment les fichiers CSS, fusionnez plusieurs définitions de la même classe. Supprimez immédiatement les définitions obsolètes .

• Lors de l'ajout de CSS lors de la correction de bogues, laissez un commentaire sur ce que fait la modification ("C'est pour vous assurer que la case est alignée à gauche dans IE <7")

• Évitez les redondances, par exemple en définissant la même chose dans .classnameet .classname:hover.

• Utilisez des commentaires /** Head **/pour construire une structure claire.

• Utilisez un outil plus joli qui aide à maintenir un style constant. J'utilise Polystyle , avec lequel je suis assez content (coûte 15 $ mais c'est de l'argent bien dépensé). Il y en a aussi autour (par exemple Code Beautifier basé sur CSS Tidy , un outil open-source).

• Construisez des classes sensées. Voir ci-dessous pour quelques notes à ce sujet.

• Utilisez la sémantique, évitez la soupe DIV - utilisez <ul>s pour les menus, par exemple.

• Définissez tout à un niveau aussi bas que possible (par exemple, une famille de polices, une couleur et une taille par défaut dans le body) et utilisez inheritsi possible

• Si vous avez un CSS très complexe, un précompilateur CSS peut être utile. Je prévois d'étudier bientôt xCSS pour la même raison. Il y en a plusieurs autres autour.

• Si vous travaillez en équipe, soulignez également la nécessité de la qualité et des normes pour les fichiers CSS. Tout le monde est grand sur les normes de codage dans leurs langages de programmation, mais il y a peu de conscience que cela est également nécessaire pour CSS.

• Si vous travaillez dans une équipe, ne pensez à utiliser le contrôle de version. Cela rend les choses beaucoup plus faciles à suivre et à éditer les conflits beaucoup plus faciles à résoudre. Cela en vaut vraiment la peine, même si vous êtes "juste" dans HTML et CSS.

• Ne travaillez pas avec !important. Non seulement parce qu'IE = <7 ne peut pas y faire face. Dans une structure complexe, l'utilisation de !importantest souvent tentante de changer un comportement dont la source est introuvable, mais c'est un poison pour la maintenance à long terme.

Construire des classes sensibles

C'est comme ça que j'aime construire des classes sensées.

J'applique d'abord les paramètres globaux:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Ensuite, j'identifie les principales sections de la mise en page - par exemple la zone supérieure, le menu, le contenu et le pied de page. Si j'ai écrit un bon balisage, ces zones seront identiques à la structure HTML.

Ensuite, je commence à construire des classes CSS, en spécifiant autant d'ascendance que possible aussi longtemps que cela est sensé, et en regroupant les classes liées aussi étroitement que possible.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Considérez l'ensemble de la structure CSS comme un arbre avec des définitions de plus en plus spécifiques, plus vous vous éloignez de la racine. Vous voulez garder le nombre de classes aussi bas que possible et vous voulez vous répéter aussi rarement que possible.

Par exemple, supposons que vous ayez trois niveaux de menus de navigation. Ces trois menus sont différents, mais ils partagent également certaines caractéristiques. Par exemple, ils sont tous <ul>, ils ont tous la même taille de police et les éléments sont tous côte à côte (par opposition au rendu par défaut d'un ul). De plus, aucun des menus n'a de puce ( list-style-type).

Tout d'abord, définissez les caractéristiques communes dans une classe nommée menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

définissez ensuite les caractéristiques spécifiques de chacun des trois menus. Le niveau 1 mesure 40 pixels de haut; niveaux 2 et 3, 20 pixels.

Remarque: vous pouvez également utiliser plusieurs classes pour cela, mais Internet Explorer 6 a des problèmes avec plusieurs classes , donc cet exemple utilise ids.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

Le balisage du menu ressemblera à ceci:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

Si vous avez des éléments sémantiquement similaires sur la page - comme ces trois menus - essayez d'abord de trouver les points communs et de les mettre dans une classe; ensuite, déterminez les propriétés spécifiques et appliquez-les aux classes ou, si vous devez prendre en charge Internet Explorer 6, les ID.

Divers conseils HTML

Si vous ajoutez cette sémantique à votre sortie HTML, les concepteurs peuvent plus tard personnaliser l'apparence des sites Web et / ou des applications à l'aide de CSS pur, ce qui est un grand avantage et un gain de temps.

• Si possible, donnez au corps de chaque page une classe unique: <body class='contactpage'>cela permet d'ajouter très facilement des ajustements spécifiques à la page à la feuille de style:

  body.contactpage div.container ul.mainmenu li { color: green }

• Lors de la création automatique de menus, ajoutez autant de contexte CSS que possible pour permettre un style étendu plus tard. Par exemple:

  <ul class="mainmenu">
   <li class="item_first item_active item_1"> First item </li> 
   <li class="item_2"> Second item </li> 
   <li class="item_3"> Third item </li> 
   <li class="item_last item_4"> Fourth item </li> 
  </ul>

  De cette façon, chaque élément de menu est accessible pour le style en fonction de son contexte sémantique: que ce soit le premier ou le dernier élément de la liste; Que ce soit l'élément actuellement actif; et par numéro.

Notez que cette affectation de plusieurs classes comme indiqué dans l'exemple ci - dessus ne fonctionne pas correctement dans IE6 . Il existe une solution de contournement pour rendre IE6 capable de gérer plusieurs classes. Si la solution de contournement n'est pas une option, vous devrez définir la classe qui est la plus importante pour vous (numéro d'article, actif ou premier / dernier), ou recourir à l'utilisation d'ID.

Voici seulement 4 exemples:

• Conventions CSS / Modèles de disposition de code
• Existe-t-il des normes CSS à suivre lors de l'écriture de ma première feuille de style?
• Quelle est la meilleure méthode pour ranger CSS?
• Meilleures pratiques - Formatage des feuilles de style CSS

Sur les 4, ma réponse incluait les conseils pour télécharger et lire les systèmes CSS PDF de Natalie Downe . (Le PDF comprend des tonnes de notes qui ne sont pas dans les diapositives, alors lisez le PDF!). Prenez note de ses suggestions d'organisation.

EDIT (2014/02/05) quatre ans plus tard, je dirais:

• Utilisez un pré-processeur CSS et gérez vos fichiers en tant que partiels (je préfère personnellement Sass avec Compass, mais Less est également assez bon et il y en a d'autres)
• Renseignez-vous sur des concepts tels que OOCSS , SMACSS et BEM ou getbem .
• Jetez un œil à la structure des frameworks CSS populaires comme Bootstrap et Zurb Foundation . Et ne négligez pas les cadres moins populaires - les Inuits sont intéressants, mais il y en a beaucoup d'autres.
• Combinez / réduisez vos fichiers avec une étape de génération sur un serveur d'intégration continue et / ou un exécuteur de tâches comme Grunt ou Gulp.

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

Jetez un oeil à 1. SASS 2. Compass

La meilleure façon que j'ai vue pour contrer les CSSballonnements est d'utiliser les principes CSS orientés objet.

Il y a même un framework OOCSS qui est assez bon.

Certaines des idéologies vont à l'encontre de beaucoup de ce qui a été dit ici dans les réponses les plus importantes, mais une fois que vous savez comment créer CSSune architecture orientée objet, vous verrez que cela fonctionne réellement pour garder le code léger et méchant.

L'essentiel ici est d'identifier les «objets» ou les modèles de blocs de construction dans votre site et d'architecter avec eux.

Facebook a embauché la créatrice de OOCSS, Nicole Sullivan pour obtenir beaucoup d'économies dans leur code frontal (HTML / CSS). Oui , vous pouvez réellement obtenir des économies non seulement dans votre CSS, mais dans votre code HTML aussi, qui , par le son de celui - ci, est très possible pour vous que vous mentionnez la conversion d' une tablemise en page basée sur un grand nombre de div« s

Une autre excellente approche est similaire dans certains aspects à OOCSS, est de planifier et d'écrire votre CSS pour être évolutif et modulaire dès le départ. Jonathan Snook a fait une brillante rédaction et livre / ebook sur SMACSS - Architecture évolutive et modulaire pour CSS

Permettez-moi de vous connecter avec quelques liens:
5 erreurs de CSS massives - (Vidéo)
5 erreurs de CSS massives - (Diapositives)
CSS Bloat - (Diapositives)

Vous devez également comprendre la cascade, le poids et leur fonctionnement.

Je remarque que vous utilisez uniquement des identificateurs de classe (div.title). Saviez-vous que vous pouvez également utiliser des identifiants et qu'un identifiant a plus de poids qu'une classe?

Par exemple,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

fera que tous ces éléments partagent une taille de police, disons, ou une couleur, ou quelles que soient vos règles. Vous pouvez même faire en sorte que toutes les DIV qui descendent de # page1 obtiennent certaines règles.

En ce qui concerne le poids, n'oubliez pas que les axes CSS passent du plus général / le plus léger au plus spécifique / le plus lourd. Autrement dit, dans un sélecteur CSS, un spécificateur d'élément est annulé par un spécificateur de classe est annulé par un spécificateur ID. Les nombres comptent, donc un sélecteur avec deux spécificateurs d'éléments (ul li) aura plus de poids qu'un seul avec un seul spécificateur (li).

Pensez-y comme des chiffres. Un 9 dans la colonne des est toujours inférieur à un dans la colonne des dizaines. Un sélecteur avec un spécificateur d'ID, un spécificateur de classe et deux spécificateurs d'élément aura plus de poids qu'un sélecteur sans ID, 500 spécificateurs de classe et 1 000 spécificateurs d'élément. C'est un exemple absurde, bien sûr, mais vous voyez l'idée. Le fait est que l'application de ce concept vous aide à nettoyer beaucoup de CSS.

BTW, l'ajout du spécificateur d'élément à la classe (div.title) n'est pas nécessaire sauf si vous rencontrez des conflits avec d'autres éléments qui ont class = "title". N'ajoutez pas de poids inutile, car vous devrez peut-être utiliser ce poids plus tard.

Puis-je suggérer moins de cadre dynamique CSS

Il est similaire au SASS comme mentionné précédemment.

Il aide à maintenir CSS par classe parent.

Par exemple

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

Action: applique une largeur: 100% à la fois à # enfant1 et # enfant2.

De plus, # CSS spécifique à child1 appartient à #parent.

Cela rendrait à

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

Je trouve que la difficulté est de traduire la conception requise pour un site en une série de règles. Si la conception du site est claire et basée sur des règles, vos noms de classe et votre structure CSS peuvent en découler. Mais si les gens ajoutent au fil du temps de petits morceaux au site qui n'ont pas beaucoup de sens, il n'y a pas grand-chose que vous puissiez faire à ce sujet dans le CSS.

J'ai tendance à organiser mes fichiers CSS à peu près comme ceci:

1. Réinitialisation CSS, basée sur celle d' Eric Meyer . (Parce que sinon, je trouve que, pour la plupart des éléments, j'ai au moins une ou deux règles qui ne font que réinitialiser les styles de navigateur par défaut - la plupart de mes listes ne ressemblent pas au style HTML par défaut pour les listes, par exemple.)

2. Système de grille CSS, si le site le demande. (Je base le mien sur 960.gs )

3. Styles pour les composants qui apparaissent sur chaque page (en-têtes, pieds de page, etc.)

4. Styles pour les composants utilisés à divers endroits du site

5. Styles qui ne sont pertinents que sur des pages individuelles

Comme vous pouvez le voir, cela dépend en grande partie de la conception du site. Si le design est clair et organisé, votre CSS peut l'être. Sinon, vous êtes foutu.

Ma réponse est de haut niveau pour répondre aux préoccupations de haut niveau que vous avez soulevées dans votre question. Il peut y avoir des astuces organisationnelles de bas niveau et des ajustements que vous pouvez faire pour les rendre plus jolis, mais aucun d'entre eux ne peut corriger les lacunes méthodologiques. Il y a plusieurs choses qui affectent l'explosion CSS. Évidemment la complexité globale du site, mais aussi des choses comme la sémantique de dénomination, les performances CSS, l'organisation des fichiers CSS et la testabilité / acceptabilité.

Vous semblez être sur la bonne voie avec la sémantique de nommage, mais cela peut aller plus loin. Les sections de HTML qui apparaissent à plusieurs reprises sur le site sans modification structurelle (appelées «modules») peuvent être considérées comme des racines de sélecteur, et à partir de là, vous pouvez étendre la disposition interne par rapport à cette racine. C'est le principe de base du CSS orienté objet , et vous pouvez en lire / regarder plus à ce sujet dans cette conférence d'un ingénieur Yahoo .

Il est important de noter que cette approche propre peut aller à l'encontre du souci de performances, qui favorise les sélecteurs courts basés sur l'id ou le nom de la balise . Trouver cet équilibre dépend de vous, mais à moins que vous n'ayez un site massif, cela ne devrait être qu'un guide à l'arrière de votre tête vous rappelant de garder vos sélecteurs courts. Plus d'informations sur les performances ici .

Enfin, allez-vous avoir un seul fichier CSS pour l'ensemble de votre site, ou plusieurs fichiers (un seul fichier de base utilisé avec des fichiers par page ou par section)? Le fichier unique est meilleur pour les performances, mais peut être plus difficile à comprendre / à gérer avec plusieurs membres de l'équipe et peut être plus difficile à tester. Pour les tests, je vous recommande d'avoir une seule page de test CSS qui inclut tous les modules CSS pris en charge pour tester les collisions et les cascades involontaires.

Alternativement, vous pouvez avoir une approche à fichiers multiples , pour étendre les règles CSS à une page ou une section. Cela nécessite que le navigateur télécharge plusieurs fichiers, ce qui est un problème de performances. Vous pouvez utiliser la programmation côté serveur pour spécifier et agréger (et réduire) les fichiers CSS en un seul fichier de manière dynamique. Mais comme ces fichiers sont séparés et que leur test serait séparé, vous introduisez la possibilité d'une apparence incohérente entre les pages / sections. Ainsi, les tests deviennent plus difficiles.

C'est à vous d'analyser les besoins spécifiques du client, d'équilibrer ces préoccupations en conséquence.

Comme je l'ai déjà dit: entrez dans l'OOCSS. Sass / Less / Compass est tentant d'utiliser, mais jusqu'à ce que CSS vanilla soit utilisé de la bonne façon, Sass / Less / Compass ne fera qu'empirer les choses.

Tout d'abord, renseignez-vous sur les CSS efficaces. essayez Google Page Speed ​​et lisez ce que Souders a écrit sur les css efficaces.

Entrez ensuite OOCSS.

• Apprenez à travailler avec la cascade. (Après tout, nous l'appelons les feuilles de style en cascade ).
• Apprenez à obtenir la bonne granularité (de bas en haut plutôt que de haut en bas)
• Apprenez à séparer la structure et la peau (qu'est-ce qui est unique et quelles sont les variations de ces objets?)
• Apprenez à séparer le conteneur et le contenu.
• Apprenez à aimer les grilles.

Il révolutionnera chaque bit sur l'écriture de CSS. Je suis totalement renouvelé et j'adore ça.

MISE À JOUR: SMACSS est similaire à OOCSS, mais plus facile à adapter d'une manière générale.

Les principes de base pour CSS sensé, extraits de CSS Refactoring: De l'ajout uniquement au CSS modulaire

Écrivez en SASS. Vous seriez fou de renoncer aux avantages des variables, des mixins, etc.

N'utilisez jamais un ID HTML pour le style; utilisez toujours des classes . Les identifiants HTML, lorsqu'ils sont utilisés correctement, n'apparaissent qu'une seule fois dans toute la page, ce qui est tout le contraire de la réutilisation - l'un des produits les plus élémentaires d'une ingénierie sensée. De plus, il est vraiment difficile de remplacer les sélecteurs contenant des ID et souvent le seul moyen de maîtriser un ID HTML est de créer un autre ID, ce qui provoque la propagation des ID dans la base de code comme les parasites qu'ils sont. Mieux vaut laisser les identifiants HTML pour le Javascript immuable ou les hooks de test d'intégration.

Nommez vos classes CSS par leur fonction visuelle plutôt que par leur fonction spécifique à l'application. Par exemple, dites ".highlight-box" au lieu de ".bundle-product-discount-box". Le codage de cette manière signifie que vous pouvez réutiliser vos feuilles de style existantes lorsque vous attribuez des activités secondaires. Par exemple, nous avons commencé par vendre des notes juridiques, mais nous avons récemment rejoint des tuteurs. Nos anciennes classes CSS avaient des noms comme ".download_document_box", un nom de classe qui a du sens lorsque l'on parle de documents numériques mais qui ne ferait que confondre lorsqu'il est appliqué au nouveau domaine des tuteurs privés. Un meilleur nom qui correspond à la fois aux services existants - et à tous les futurs - serait ".pretty_callout_box".

Évitez de nommer les classes CSS après des informations de grille spécifiques. Il y avait (et il y a toujours) un anti-modèle redoutable dans les communautés CSS selon lequel les concepteurs et les créateurs de frameworks CSS (toussent Twitter Bootstrap ) croient que "span-2" ou "cols-8" sont des noms raisonnables pour les classes CSS. Le but du CSS est de vous donner la possibilité de modifier votre design sans trop affecter le balisage. Le codage en dur des tailles de grille dans le HTML contrecarre cet objectif, il est donc déconseillé dans tout projet qui devrait durer plus d'un week-end. Plus d'informations sur la façon dont nous avons évité les classes de grille plus tard.

Répartissez votre CSS sur plusieurs fichiers . Idéalement, vous diviseriez tout en "composants" / "widgets", puis vous composeriez des pages à partir de ces atomes de conception. De manière réaliste, vous remarquerez que certaines pages de votre site Web présentent des particularités (par exemple, une mise en page spéciale ou une galerie de photos étrange qui apparaît dans un seul article). Dans ces cas, vous pouvez créer un fichier lié à cette page spécifique, en le refactorisant uniquement dans un widget complet lorsqu'il devient clair que l'élément sera réutilisé ailleurs. Il s'agit d'un compromis, motivé par des préoccupations budgétaires pratiques.

Minimisez la nidification. Introduisez de nouvelles classes au lieu d'imbriquer des sélecteurs. Le fait que SASS supprime la douleur de la répétition des sélecteurs lors de l'imbrication ne signifie pas que vous devez imbriquer cinq niveaux en profondeur. Ne surqualifiez jamais un sélecteur (par exemple, n'utilisez pas "ul.nav" où ".nav" pourrait faire le même travail.) Et ne spécifiez pas d'éléments HTML à côté du nom de classe personnalisé (par exemple "h2.highlight"). Au lieu de cela, utilisez simplement le nom de classe et déposez le sélecteur de base (par exemple, l'exemple précédent devrait être ".highlight"). La surqualification des sélecteurs n'ajoute aucune valeur.

Créez des styles pour les éléments HTML (par exemple "h1") uniquement lorsque vous stylisez des composants de base qui doivent être cohérents dans l'ensemble de l'application. Évitez les sélecteurs larges comme "header ul" car il est probable que vous deviez les remplacer à certains endroits de toute façon. Comme nous le répétons, la plupart du temps, vous voulez utiliser une classe spécifique et bien nommée chaque fois que vous voulez un style particulier.

Adoptez les bases de Block-Element-Modifier. Vous pouvez lire à ce sujet par exemple ici. Nous l'avons utilisé assez légèrement, mais cela nous a quand même beaucoup aidé à organiser les styles CSS.

Souvent, je verrai des individus diviser le fichier en sections, avec un commentaire de titre entre les sections.

Quelque chose comme

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

Cela fonctionne assez bien et peut faciliter le retour en arrière et trouver ce sur quoi vous travaillez.

Vous devriez regarder BEM .

Théorie

BEM est une tentative de fournir un ensemble d'instructions pour organiser et nommer les sélecteurs css dans le but de rendre les choses plus réutilisables et modulaires et d'éviter les conflits entre les sélecteurs du type qui conduit souvent à du code spaghetti et à des maux de tête de spécificité.

Lorsqu'il est utilisé correctement, il a en fait des effets très positifs.

• Les styles font ce que vous attendez lorsqu'ils sont ajoutés à un élément
• Les styles ne fuient pas et n'effectuent que ce à quoi ils sont ajoutés
• Les styles sont complètement découplés de la structure du document
• Les styles n'ont pas besoin d'être forcés de se surpasser

BEM fonctionne bien avec SASS pour apporter un style presque orienté objet à CSS. Vous pouvez créer des fichiers modulaires, qui gèrent l'affichage d'un seul élément d'interface utilisateur et contiennent des variables, telles que les couleurs et des «méthodes» telles que la façon dont les éléments internes sont traités. Bien qu'un programmeur OO inconditionnel puisse reculer à cette idée, en fait, les concepts appliqués apportent beaucoup de parties plus agréables des structures OO, telles que la modularité, le couplage lâche et la cohésion étroite et la réutilisation sans contexte. Vous pouvez même construire d'une manière qui ressemble à un objet encapsulé en utilisant Sass et l' &operato r.

Un article plus approfondi de Smashing Magazine peut être trouvé ici ; et un de Harry Roberts de CCS Wizardry (dont toute personne impliquée dans css devrait avoir une lecture) est ici .

En pratique

Je l'ai utilisé plusieurs fois, en plus d'avoir utilisé SMACSS et OOCSS, ce qui signifie que j'ai aussi quelque chose à comparer. J'ai également travaillé dans de gros bazar, souvent de ma propre création, sans expérience.

Lorsque j'utilise BEM dans le monde réel, j'augmente la technique avec quelques principes supplémentaires. J'utilise des classes utilitaires - un bon exemple est une classe wrapper:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

Et je me fie aussi un peu à la cascade et à la spécificité. Ici, le module BEM serait .primary-boxet .headerserait le contexte d'un dépassement spécifique

.header {
  .primary-box {
    color: #000;
  }
}

(Je fais de mon mieux pour que tout soit aussi générique et sans contexte que possible, ce qui signifie un bon projet presque tout est dans les modules qui sont réutilisables)

Un dernier point que je ferais ici est que, même si votre projet est petit et peu complexe, vous devriez le faire dès le début, pour deux raisons:

• la complexité des projets augmente, il est donc important de poser de bonnes bases, css inclus
• même un projet qui semble simple parce qu'il est construit sur WordPress a peu de JavaScript peut toujours être très complexe dans le CSS - OK, vous n'avez pas à faire de codage côté serveur, donc cette partie est simple, mais le frontal de la brochure a vingt modules et trois variantes de chacun: vous avez là des CSS très complexes!

Composants Web

En 2015, nous commençons à examiner les composants Web. Je ne connais pas encore grand-chose à ce sujet, mais ils cherchent à rassembler toutes les fonctionnalités frontales dans des modules autonomes, essayant efficacement d'appliquer les types de principes de BEM à l'ensemble frontal et de composant dispersé mais entièrement couplé des éléments tels que des fragments DOM, Js (MVC) et CSS qui construisent tous le même widget d'interface utilisateur.

En faisant cela, ils résoudront certains des problèmes d'origine qui existent avec css que nous avons essayé de résoudre avec des choses comme BEM, tout en rendant certaines autres architectures frontales plus saines.

Il y a quelques lectures supplémentaires ici et aussi un cadre Polymer ici qui vaut bien un coup d'oeil

finalement

Je pense également que c'est un excellent guide css de meilleures pratiques moderne - conçu spécifiquement pour empêcher les grands projets css de devenir salissants. J'essaie de suivre la plupart d'entre eux.

Je vous recommanderais de regarder le framework CSS "Compass Style" .

il y a du bon matériel ici et certains ont pris beaucoup de temps pour répondre à cette question cependant quand il s'agit de feuilles de style séparées ou individuelles, j'irais avec des fichiers séparés pour le développement, puis j'utiliserais tous vos CSS génériques à travers le site fusionné dans un seul fichier une fois déployé.

de cette façon, vous avez le meilleur des deux mondes, améliore les performances (moins de requêtes HTTP demandées au navigateur) et la séparation des problèmes de code lors du développement.