Question Gérer l'explosion CSS


J'ai beaucoup compté sur CSS pour un site web sur lequel je travaille. À l'heure actuelle, tous les styles CSS sont appliqués par tag, et maintenant j'essaie de le déplacer vers un style plus externe pour aider à tout changement futur.

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

J'utilise un grand nombre de div tags sur le site Web, se déplaçant d'un site Web fortement basé sur la table. Donc, je reçois 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 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 un attribut CSS distinct pour chaque élément de mon site Web, et je veux toujours que le fichier CSS soit assez intuitif et facile à lire.

Mon but ultime est de faciliter l'utilisation des fichiers CSS et de démontrer leur capacité à accélérer le développement Web. De cette façon, d'autres personnes qui pourraient travailler sur ce site dans le futur vont aussi entrer dans la pratique d'utiliser de bonnes pratiques de codage, plutôt que d'avoir à le faire comme je l'ai fait.


668
2018-02-12 16:03


origine


Réponses:


C'est une très bonne question. Partout où je regarde, les fichiers CSS ont tendance à devenir hors de contrôle après un certain temps - en particulier, mais pas seulement, lorsque vous travaillez en équipe.

Voici les règles auxquelles je suis moi-même en train d'adhérer (ce que je n'arrive pas toujours à faire.)

  • Refactoriser tôt, refactoriser souvent. Nettoyer fréquemment les fichiers CSS, fusionner plusieurs définitions de la même classe. Supprimer les définitions obsolètes immédiatement.

  • Lors de l'ajout de CSS lors de la correction de bugs, laissez un commentaire sur ce que le changement fait ("Ceci est pour s'assurer que la boîte est alignée à gauche dans IE <7")

  • Évitez les redondances, par ex. définir la même chose dans .classname et .classname:hover.

  • Utiliser les commentaires /** Head **/ pour construire une structure claire.

  • Utilisez un outil de préchauffage qui aide à maintenir un style constant. j'utilise Polystyle, avec lequel je suis assez heureux (coûte 15 $ mais c'est de l'argent bien dépensé). Je suis sûr qu'il y en a aussi des gratuits (Mise à jour: comme par exemple Code Beautifier basé sur CSS Tidy, un outil open source que je n'ai pas encore utilisé mais qui semble très intéressant.)

  • Construire des classes sensibles. 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 sur un niveau aussi bas que possible (par exemple, une famille de polices par défaut, la couleur et la taille dans le body) et utilise inherit lorsque c'est possible

  • Si vous avez des CSS très complexes, un pré-compilateur CSS peut être utile. Je prévois de regarder dans xCSS pour la même raison bientôt. Il y en a plusieurs autres autour.

  • Si vous travaillez en équipe, mettez en évidence la nécessité de la qualité et des normes pour les fichiers CSS. Tout le monde a de grandes exigences en matière de codage dans leur (s) langage (s) de programmation, mais il y a peu de prise de conscience que cela est également nécessaire pour les CSS.

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

  • Ne travaille pas avec !important. Non seulement parce que IE = <7 ne peut pas le gérer. Dans une structure complexe, l'utilisation de! Important est souvent tentante pour changer un comportement dont on ne trouve pas la source, mais c'est poison pour l'entretien à long terme.

Construire des classes sensibles

C'est comme ça que j'aime construire des classes sensibles.

J'applique les paramètres globaux en premier:

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

Ensuite, j'identifie les sections principales de la mise en page - par ex. 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 et raisonnable, 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

Pensez à toute la structure CSS en tant que arbre avec des définitions de plus en plus spécifiques, plus loin de la racine vous êtes. Vous voulez garder le nombre de classes aussi bas que possible, et vous voulez vous répéter aussi rarement que possible.

Par exemple, disons que vous avez trois niveaux de menus de navigation. Ces trois menus semblent 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 les uns à côté des autres (par opposition au rendu par défaut d'un ul). De plus, aucun des menus n'a de puce (list-style-type).

D'abord, définissez le commun caractéristiques 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 }

Ensuite, définissez les caractéristiques spécifiques de chacun des trois menus. Le niveau 1 mesure 40 pixels de hauteur; 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 d'établir les points communs et de les mettre dans une classe; puis, développez les propriétés spécifiques et appliquez-les aux classes ou, si vous devez prendre en charge Internet Explorer 6, ID.

Conseils HTML divers

Si vous ajoutez ces sémantiques dans votre sortie HTML, les concepteurs peuvent personnaliser l'aspect des sites Web et / ou des applications en utilisant du CSS pur, ce qui est un avantage et un gain de temps.

  • Si possible, donnez au corps de chaque page une classe unique: <body class='contactpage'> cela rend très facile l'ajout de réglages spécifiques à la feuille de style:

    body.contactpage div.container ul.mainmenu li { color: green }
    
  • Lorsque vous construisez des menus automatiquement, 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 peut être consulté pour le style en fonction de son contexte sémantique: s'il s'agit du premier ou du dernier élément de la liste; Que ce soit l'élément actuellement actif; et par numéro.

Remarque que cette assignation de plusieurs classes comme indiqué dans l'exemple ci-dessus ne fonctionne pas correctement dans IE6. Il y a un solution de contournement rendre IE6 capable de gérer plusieurs classes; Je n'ai pas encore essayé, mais semble très prometteur, venant de Dean Edwards. Jusque-là, vous devrez définir la classe qui vous intéresse le plus (numéro d'article, actif ou premier / dernier) ou utiliser des ID. (Booo IE6!)


551
2018-02-12 16:39



Voici juste 4 exemples:

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

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

  • Utiliser un pré-processeur CSS et gérer vos fichiers en tant que partiels (je préfère personnellement Sass avec Compass, mais Less est assez bon aussi et il y en a d'autres)
  • Lisez des concepts comme OOCSS, SMACSS, et BEM ou getbem.
  • Jetez un oeil à la façon dont les cadres populaires CSS comme Bootstrap et Fondation Zurb sont structurés. Et ne pas négliger les cadres moins populaires - Inuit C'est intéressant mais il y en a plein d'autres.
  • Combinez / réduisez vos fichiers avec une étape de construction sur un serveur d'intégration continue et / ou un coureur de tâches comme Grunt ou Gulp.

87
2018-01-20 17:16



Ne pas écrire les en-têtes en CSS

Il suffit de diviser les sections en fichiers. Tous les commentaires CSS, devraient être juste cela, 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 structure de répertoires sympa, et faire scanner votre script de manière récursive .css des dossiers.

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 écrivez plus tard. C'est une douleur de chercher des rubriques. Pour ajouter au problème, comment exactement quelqu'un est-il supposé savoir que vous avez un autre en-tête après votre premier en-tête? ps. N'ajoutez pas doc-like * (étoile) au début de chaque ligne lorsque vous écrivez des tables des matières, cela rend plus gênant de sélectionner le 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 modifiez le script, il y a 50% de chances que vous fassiez attention à ce qui se trouve en dehors du bloc de règles (en particulier s'il s'agit d'un gros glob de texte;)). Deuxièmement, il n'y a (presque) aucun cas où vous auriez besoin d'un «commentaire» à l'extérieur. Si c'est à l'extérieur, c'est 99% du temps un titre, alors gardez-le comme ça.

Diviser la page en composants

Les composants devraient avoir position:relative, non padding et non margin, la plupart du temps. Cela simplifie beaucoup le% de règles, tout en permettant beaucoup plus simple absolute:positiondes éléments, car s'il existe un conteneur positionné en absolu, l'élément positionné absolu utilisera le conteneur lors du calcul top, right, bottom, left Propriétés.

La plupart des DIV dans un document HTML5 sont généralement un composant.

Un composant est aussi 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 un boîte noire.

Aller à nouveau avec l'exemple de page QA:

#navigation
#question
#answers
#answers .answer
etc.

En divisant la page en composants, vous divisez votre travail en unités gérables.

Mettez des règles avec un effet cumulatif sur la même ligne.

Par exemple border, margin et padding (mais non outline) tout ajouter aux dimensions et la taille de l'élément que vous stylisez.

position: absolute; top: 10px; right: 10px;

Si elles ne sont pas lisibles sur une ligne, mettez-les au moins à proximité:

padding: 10px; margin: 20px;
border: 1px solid black;

Utilisez la sténographie 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 plus d'instances du même sélecteur, il y a de fortes chances que vous finissiez inévitablement par 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.

Ce...

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;
}

Devrait ê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 DIVs qui pendent ne rajoutent rien au sélecteur. Ils forcent également une règle de tag inutile. Si vous deviez changer, par exemple, .answer de div à un article ton style se casserait.

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 étant la border-collapse propriété est une propriété spéciale qui n'a de sens qu'une fois appliquée à un table. Si .statistics n'est pas un table 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
  • sauf pour un CSS-reset / unreset, toute votre magie générique devrait s'appliquer à au moins un composant racine

Ils ne vous font pas gagner du temps, ils font exploser votre tête; ainsi que faire de la maintenance un cauchemar. Lorsque vous écrivez la règle, vous pouvez savoir où ils s'appliquent, mais cela ne garantit pas que votre règle ne vous dérangera pas plus tard.

Ajouter à ces règles génériques est déroutant et difficile à lire, même si vous avez une idée du document que vous stylisez. Cela ne veut pas dire que vous ne devriez pas écrire de règles génériques, ne les utilisez pas à moins que vous n'ayez vraiment l'intention 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 la portée!

#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 identifiants chaque fois qu'un composant que je connais est un singleton sur une page; vos besoins peuvent être différents.

Note: Idéalement, vous devriez écrire juste assez. Mentionner plus de composants dans le sélecteur est cependant l'erreur la plus indulgente, comparé à mentionner moins de composants.

Supposons que vous avez un paginationcomposant. Vous l'utilisez dans de nombreux endroits sur votre site. Ce serait un bon exemple de quand vous écrivez une règle générique. Disons toi display:block les liens de numéro de page individuels et 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;
}

Maintenant disons 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 de bla-bla combinée avec la hauteur de 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, pensez à l'un de ces langages de template CSS comme TOUPET ou MOINS.

Comment faites-vous que j'écris une palette de couleur?

Laissez ceci pour la fin. Avoir un fichier pour l'ensemble de votre palette de couleurs. Avec ce fichier, votre style devrait toujours avoir une palette de couleur utilisable dans les règles. Votre palette de couleurs doit remplacer. Vous enchaînez les sélecteurs en utilisant un composant parent de très haut niveau (par ex. #page), puis écrivez votre style en tant que bloc de règles auto-suffisant. Cela peut être juste 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, que vous Cascade dans.

Moins de noms, nécessite moins de mémoire, ce qui facilite la lecture du code

Utiliser moins de noms est mieux. Idéalement, utilisez des mots très simples (et courts!): Texte, corps, en-tête.

Je trouve aussi que la combinaison de mots simples est plus facile à comprendre que d'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 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 où chaque sélecteur est utilisé. Par exemple j'utilise .this chaque fois qu'un élément est supposé "l'élément sélectionné" ou "l'élément actuel", etc.

Nettoyez après vous

Écrire CSS est comme manger, parfois vous laissez un désordre derrière. Assurez-vous de nettoyer ce désordre, sinon le code de déchet 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 est bien et que vous n'avez pas de règles contradictoires ou dupliquées.

Si vous, comme je l'ai suggéré, traitait certains conteneurs comme des boîtes noires (composants) dans votre style, utilisiez ces composants dans vos sélecteurs et conserviez tout dans un fichier dédié (ou divisiez correctement un fichier avec une table des matières et des en-têtes). le travail est sensiblement 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 une partie de la camelote cachée dans vos bombes nucléaires et vos carnies.

Garder un unsorted.css fichier

Supposons que vous stylisez un site d'assurance qualité et que vous ayez déjà une feuille de style pour la "page de réponses", que nous appellerons answers.css. Si vous avez maintenant besoin d'ajouter beaucoup de nouveaux CSS, ajoutez-les au unsorted.css stylesheet puis refactoriser dans votre answers.css feuille de style.

Plusieurs raisons à cela:

  • il est plus rapide de refactoriser après que vous ayez fini, alors c'est de chercher des règles (qui n'existent probablement pas) et d'injecter du code
  • vous allez écrire des choses que vous supprimerez, l'injection de code rendra plus difficile le retrait de ce code
  • l'ajout au fichier d'origine entraîne facilement la duplication des règles / sélecteurs

72
2017-08-08 12:57



Jettes un coup d'oeil à 1. TOUPET 2. Boussole


55
2018-01-27 05:18



Le meilleur moyen que j'ai vu pour contrer CSS bloat utilise les principes CSS orientés objet.

Il y a même un OOCSS cadre là-bas c'est plutôt bien.

Certaines idéologies vont à l'encontre de ce qui a été dit ici dans les meilleures réponses, mais une fois que l'on sait comment l'architecte CSS d'une manière orientée objet, vous verrez que cela fonctionne réellement pour garder le code maigre et méchant.

L'élément clé ici est d'identifier les «Objets» ou les modèles de blocs de construction dans votre site et l'architecte avec eux.

Facebook a embauché le créateur de OOCSS, Nicole Sullivan pour obtenir beaucoup d'économies dans leur code frontal (HTML / CSS). Oui, vous pouvez réellement faire des économies non seulement sur votre CSS, mais aussi sur votre HTML, ce qui est très possible pour vous comme vous le mentionnez convertir un table mise en page basée dans beaucoup de divde

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 un brillant écrire et livre / ebook sur SMACSS - Architecture évolutive et modulaire pour CSS

Laissez-moi vous raconter quelques liens:
5 erreurs de CSS massives - (Vidéo)
5 erreurs de CSS massives - (Diapositives)
CSS Bloat - (Diapositives) 


31
2018-02-12 16:46



Vous devriez également comprendre la cascade et le poids, et comment ils fonctionnent.

Je remarque que vous utilisez uniquement des identifiants 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 en sorte 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 sont des descendants de # page1 obtiennent certaines règles.

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

Pensez-y comme des chiffres. Une colonne de 9 dans les uns est toujours inférieure à une 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éments. C'est un exemple absurde, bien sûr, mais vous avez l'idée. Le fait est, l'application de ce concept vous aide à nettoyer beaucoup de CSS.

BTW, ajouter le spécificateur d'élément à la classe (div.title) n'est pas nécessaire, sauf si vous êtes en conflit 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.


16
2018-04-07 19:28



Puis-je suggerer Moins de cadre dynamique CSS

Il est similaire à 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
   }
 }

Qu'est-ce que cela fait: Applique la largeur: 100% à # 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;
}

13
2018-02-12 16:32