Gestion de l'explosion de CSS

Question

Je me suis beaucoup inspiré de CSS pour le site Web sur lequel je travaille. À l'heure actuelle, tous les styles CSS sont appliqués par balise. J'essaie donc de le déplacer davantage vers un style externe pour faciliter les modifications futures.

Mais maintenant, le problème est que j'ai remarqué que je subissais une "explosion CSS". Il devient difficile pour moi de décider de la meilleure manière d’organiser et d’abstraire les données dans le fichier CSS.

J'utilise un grand nombre de balises div sur le site Web, passant d'un site Web fortement basé sur des tableaux. 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 débutant, je me demandais s'il était possible de faire des recommandations sur la meilleure façon d'organiser les différentes parties d'un fichier CSS. Je ne souhaite pas avoir d'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 objectif 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 susceptibles de travailler sur ce site à l'avenir se lanceront également dans la pratique consistant à utiliser de bonnes pratiques de codage, plutôt que de devoir les reprendre comme je l'ai fait.

Pekka 웃 · Accepted Answer

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

Voici les règles que je suis moi-même en train d'essayer de respecter (même si je réussis toujours à le faire).

Refactor tôt, refactor souvent. Nettoyez fréquemment les fichiers CSS, Fusionnez 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 le résultat de la modification ("Ceci afin de s'assurer que la zone est laissée alignée dans IE <7")
Évitez les redondances, par exemple définir la même chose dans .classname et .classname:hover.
Utilisez les commentaires /** Head **/ pour créer une structure claire.
Utilisez un outil de prétraitement qui aide à maintenir un style constant. J'utilise Polystyle , avec lequel je suis assez content (coûte 15 $ mais l'argent est bien dépensé). Je suis sûr qu’il existe également des versions gratuites (Mise à jour: comme par exemple Code Beautifier basé sur CSS Tidy , un outil open source que je n'ai pas encore utilisé moi-même mais qui semble très intéressant.)
Construire des classes sensibles. Voir ci-dessous pour quelques notes à ce sujet.
Utilisez la sémantique, évitez les soupes DIV - utilisez, par exemple, <ul>s pour les menus.
Définissez tous les éléments au niveau le plus bas possible (par exemple, une famille de polices, une couleur et une taille par défaut dans la section body) et utilisez inherit si possible.
Si vous avez un CSS très complexe, un pré-compilateur CSS peut vous aider. Je prévois d’examiner xCSS bientôt pour la même raison. Il y en a plusieurs autres autour.
Si vous travaillez en équipe, soulignez également la nécessité de qualité et de normes pour les fichiers CSS. Tout le monde a à cœur les normes de codage dans son (ses) langage (s) de programmation, mais il est peu connu que cela est également nécessaire pour CSS.
Si vous travaillez en équipe, ne envisagez d'utiliser le contrôle de version. Cela rend les choses beaucoup plus faciles à suivre et les conflits d’édition beaucoup plus faciles à résoudre. Cela en vaut vraiment la peine, même si vous êtes "juste" en HTML et CSS.
Ne travaillez pas avec !important. Pas seulement parce que IE = <7 ne peut pas s'en occuper. Dans une structure complexe, l'utilisation de! Important est souvent tentante pour changer un comportement dont la source est introuvable, mais c'est un poison pour une maintenance à long terme.

Construire des classes sensibles

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

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

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

Ensuite, j'identifie les sections principales de la mise en page - par exemple. la zone supérieure, le menu, le contenu et le pied de page. Si j'écris 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 de manière 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

Considérez la structure CSS dans son ensemble 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 vous répétez le moins possible.

Par exemple, supposons que vous disposiez de trois niveaux de menus de navigation. Ces trois menus ont un aspect différent, 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 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).

Commencez par définir les caractéristiques communes 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 }

ensuite, définissez les caractéristiques spécifiques de chacun des trois menus. Le niveau 1 fait 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 , cet exemple utilise donc ids.

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

Le balisage pour le 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 placer 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 identifiants.

Divers conseils HTML

Si vous ajoutez cette sémantique à votre sortie HTML, les concepteurs peuvent personnaliser l'apparence des sites Web et/ou des applications à l'aide de CSS pur, ce qui constitue un avantage considérable et une économie de temps.

Si possible, attribuez une classe unique au corps de chaque page: <body class='contactpage'> ceci facilite l'ajout d'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 ultérieurement. 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> 
```
Ainsi, chaque élément de menu est accessible pour un 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 un solution de contournement pour permettre à IE6 de gérer plusieurs classes; Je ne l'ai pas encore essayée, mais Dean Edwards semble très prometteur. Jusque-là, vous devrez définir la classe la plus importante pour vous (numéro d'élément, actif ou premier/dernier) ou recourir à des identifiants. (booo IE6!)

Andy Ford · Answer

Voici seulement 4 exemples:

Sur tous les 4 ma réponse a inclus le conseil de télécharger et de lire les systèmes CSS PDF de Natalie Downe _ . (Le PDF inclut des tonnes de notes qui ne figurent 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:

Utilisez un pré-processeur CSS et gérez vos fichiers comme partiels (personnellement, je préfère Sass avec Compass, mais Less est tout à fait aussi bien et il y en a d'autres)
Découvrez des concepts tels que OOCSS , SMACSS et BEM ou getbem .
Jetez un coup d'œil à la structure des infrastructures CSS populaires telles que Bootstrap et Zurb Foundation . Et ne négligez pas les cadres moins populaires - Inuit est intéressant, mais il en existe beaucoup d'autres.
Combinez/réduisez vos fichiers avec une étape de compilation sur un serveur d'intégration continue et/ou un exécuteur de tâches tel que Grunt ou Gulp.

srcspider · Answer

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

Il suffit de scinder des sections en fichiers. Tous les commentaires CSS ne devraient être que 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 structure de répertoires Nice et simplement faire analyser votre script de manière récursive pour les fichiers _.css_.

Si vous devez écrire des en-têtes, placez une table des matières au début du fichier.

Les en-têtes de la table des matières doivent être parfaitement égaux à ceux que vous écrivez plus tard. C'est pénible de chercher des titres. Pour ajouter au problème, comment peut-on savoir que vous avez un autre en-tête après votre premier en-tête? ps. N'ajoutez pas de type doc * (étoile) au début de chaque ligne lorsque vous écrivez 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 modifiez le script, vous avez une chance sur 50 que vous fassiez attention à ce qui se trouve en dehors du bloc de règles (en particulier s'il s'agit d'un gros globe de texte;)). Deuxièmement, il n’ya (presque) aucun cas où vous auriez besoin d’un "commentaire" à l’extérieur. Si c'est en dehors, c'est 99% du temps un titre, alors gardez-le comme ça.

Fractionner la page en composants

Les composants doivent avoir _position:relative_, no padding et no margin, la plupart du temps. Cela simplifie énormément% les règles, tout en permettant de simplifier beaucoup plus _absolute:position_ 'éléments, car s'il y a un conteneur positionné en absolu, l'élément positionné en absolu utilisera le conteneur lors du calcul de top, right, bottom, left propriétés.

La plupart des DIV dans 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 scindant la page en composants, vous divisez votre travail en unités gérables.

Placez des règles ayant un effet cumulatif sur la même ligne.

Par exemple, border, margin et padding (mais pas outline) s'ajoutent tous aux dimensions et à la taille de l'élément que vous stylisez.

_position: absolute; top: 10px; right: 10px; _

S'ils ne sont tout simplement pas lisibles sur une seule ligne, mettez-les au moins à proximité:

_padding: 10px; margin: 20px; border: 1px solid black; _

Utilisez le raccourci si possible:

_/* the following... */ padding-left: 10px; padding-right: 10px; /* can simply be written as */ padding: 0 10px; _

Ne jamais répéter un sélecteur

Si vous avez plusieurs instances du même sélecteur, il y a de fortes chances pour que vous finissiez 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 balises 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! ;) Ne les utilisez que 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; } _

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 DIV supplémentaires pendantes n’ajoutent rien au sélecteur. Ils imposent également une règle de tag inutile. Si vous deviez changer, par exemple, _.answer_ d'un div à un article votre 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 propriété _border-collapse_ est une propriété spéciale qui n'a de sens que lorsqu'elle est appliquée à un table. Si _.statistics_ n'est pas un table, il ne devrait pas s'appliquer.

Les règles génériques sont diaboliques!

évitez d’écrire des règles génériques/magiques si vous le pouvez
sauf s'il s'agit 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 du temps, ils vous font exploser la tête; ainsi que faire de la maintenance un cauchemar. Lorsque vous écrivez la règle, vous pouvez savoir où elles s'appliquent, mais cela ne garantit pas que votre règle ne vous importunera pas plus tard.

Ajouter à cela des règles génériques est déroutant et difficile à lire, même si vous avez une idée du document que vous appelez. Cela ne veut pas dire que vous ne devriez pas écrire de règles génériques, mais ne les utilisez pas sauf si vous voulez vraiment qu'elles soient génériques, et même qu'elles ajoutent autant d'informations de portée que vous le pouvez au 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 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 des identifiants lorsqu'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. Mentir plus de composants dans le sélecteur est cependant l'erreur la plus facile, comparé à moins de composants.

Supposons que vous avez un composant pagination. Vous l'utilisez dans de nombreux endroits sur votre site. Ce serait un bon exemple du moment où vous écririez une règle générique. Disons que vous _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 ceci

_#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 résoudre ce problème est la suivante:

_.pagination .pagelist a { color: #fff !important; } _

La bonne façon de résoudre ce problème est la suivante:

_#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é avec la hauteur du bla-bla", il est inévitable que vous commettiez une erreur et que tout s'écroule comme un château de cartes.

Gardez vos commentaires simples; si vous avez besoin "d'opérations logiques", considérez un de ces langages CSS comme SASS ou MOINS .

Comment puis-je écrire une palette de couleurs?

Laissez ceci 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 devrait écraser. Vous enchaînez des sélecteurs en utilisant un composant parent de très haut niveau (par exemple, _#page_), puis écrivez votre style en tant que bloc de règles autonome. Ce peut être juste 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 lequel vous cascade .

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

Utiliser moins de noms, c'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 qu’à une soupe de longs mots "appropriés": postbody, post-tête, userinfo, etc.

Ainsi, gardez le vocabulaire petit, même si un étranger qui vient lire votre style-soupe (comme vous au bout de quelques semaines;)) a seulement besoin de comprendre où les mots sont utilisés plutôt que chaque sélecteur. Par exemple, j'utilise _.this_ chaque fois qu'un élément est censé être "l'élément sélectionné" ou "l'élément actuel", etc.

Nettoyez après vous

Ecrire du CSS, c'est comme manger, parfois on laisse un désordre derrière soi. Assurez-vous de nettoyer ce gâchis, sinon le code de la poubelle s'empilera. Supprimez les classes/identifiants que vous n'utilisez pas. Supprimez les règles CSS que vous n'utilisez pas. Assurez-vous que tout est sympa et que vous n'avez pas de règles contradictoires ou dupliquées.

Si, comme je l’ai suggéré, certains conteneurs étaient considérés comme des boîtes noires (composants) dans votre style, si vous utilisiez ces composants dans vos sélecteurs et si vous conserviez tout dans un fichier dédié (ou si vous scindiez correctement un fichier avec une table des matières et des en-têtes), le travail est considérablement 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 malbouffe cachée dans vos css nukes et carnies.

Conserver un fichier _`unsorted.css`_

Supposons que vous appelez 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 devez maintenant ajouter beaucoup de nouveaux CSS, ajoutez-les à la feuille de style _unsorted.css_ puis refactorisez-les dans votre feuille de style _answers.css_.

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 allez supprimer, l'injection de code rend simplement plus difficile la suppression de ce code
l’ajout au fichier d’origine mène facilement à la duplication de règles/sélecteurs

Zimbabao · Answer

Jetez un oeil à 1. SASS 2. Compass

Moin Zaman · Answer

La meilleure façon que j'ai vue de contrer CSS bloat consiste à utiliser les principes CSS orientés objet.

Il existe même un cadre OOCSS assez bon.

Certaines des idéologies vont à l'encontre de ce qui a été dit ici dans les réponses principales, mais une fois que vous savez comment architecturer CSS de manière orientée objet, vous constaterez qu'il fonctionne réellement pour que le code reste simple et rationnel.

L'essentiel ici est d'identifier les "objets" ou les modèles de blocs de construction de votre site et d'architecte avec eux.

Facebook a embauché le créateur de OOCSS, Nicole Sullivan pour obtenir de nombreuses économies sur leur code frontal (HTML/CSS). Oui, vous pouvez réellement réaliser des économies non seulement dans votre code CSS, mais également dans votre code HTML, ce qui est tout à fait possible, car vous parlez de la conversion d'une mise en page basée sur table en beaucoup de div's

Une autre approche intéressante, similaire à certains aspects du logiciel OOCSS, consiste à planifier et à écrire votre code CSS pour qu'il soit évolutif et modulaire dès le départ. Jonathan Snook a brillamment écrit et écrit un livre/ebook sur SMACSS - Architecture modulaire et évolutive pour CSS

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

Robusto · Answer

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 en sorte que tous ces éléments partagent une taille de police, par exemple, une couleur ou quelles que soient vos règles. Vous pouvez même faire en sorte que toutes les DIV qui sont les 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. C'est-à-dire que dans un sélecteur CSS, un spécificateur d'élément est remplacé par un spécificateur de classe, mais également par un spécificateur d'ID. Les nombres comptent, donc un sélecteur avec deux spécificateurs d'élément (ul li) aura plus de poids qu'un sélecteur avec un seul spécificateur (li).

Pensez-y comme des chiffres. Un 9 dans la colonne des unités 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. Ceci est un exemple absurde, bien sûr, mais vous avez l’idée. Le fait est que l'application de ce concept vous aide à nettoyer beaucoup de CSS.

Par ailleurs, 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 ayant class = "title". N'ajoutez pas de poids inutile, car vous devrez peut-être utiliser ce poids plus tard.

Abhishek Mehta · Answer

Puis-je suggérer moins de cadre dynamique CSS

C'est semblable au SASS comme mentionné précédemment.

Cela aide à maintenir les CSS par classe parent.

Par exemple.

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

Signification: Applique width: 100% à # enfant1 et # enfant2.

De plus, # CSS spécifique à l'enfant1 appartient à #parent.

Cela rendrait à

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

Paul D. Waite · Answer

Je trouve que la difficulté réside dans la traduction de 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, les noms de classe et la structure CSS peuvent en découler. Mais si, au fil du temps, les utilisateurs ajoutent au hasard des éléments au site qui n’ont pas beaucoup de sens, il n’ya pas grand chose que vous puissiez faire à ce sujet dans le CSS.

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

Comme vous pouvez le constater, 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.

G-Wiz · Answer

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 Tweak que vous pouvez faire pour le rendre plus joli, mais aucun de ceux-ci ne peut réparer les lacunes méthodologiques. Plusieurs facteurs affectent l'explosion de CSS. Évidemment, la complexité générale du site, mais aussi des choses comme la sémantique de nommage, 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 encore plus loin. Les sections de HTML apparaissant de manière répétée sur le site sans modification structurelle (appelées "modules") peuvent être considérées comme des racines de sélecteur. À partir de là, vous pouvez définir la disposition interne par rapport à cette racine. Ceci est le principe de base de CSS orienté objet , et vous pouvez lisez/regardez plus à ce sujet dans cette présentation par un ingénieur de Yahoo .

Il est important de noter que cette approche propre peut aller à l'encontre du souci de performance, ce qui favorise les sélecteurs courts basés sur l'id ou le nom de la balise . Il vous appartient de trouver cet équilibre, mais à moins que vous n'ayez un site gigantesque, il ne vous reste plus qu'à vous guider à l'arrière de la tête pour vous rappeler de garder vos sélecteurs brefs. Plus sur la performance ici .

Enfin, allez-vous avoir un fichier CSS unique pour l'ensemble de votre site, ou plusieurs fichiers (un seul fichier de base utilisé avec une page ou une section) des dossiers)? Les performances d’un fichier unique sont meilleures, mais peuvent être plus difficiles à comprendre/à gérer avec plusieurs membres de l’équipe et à tester. Pour les tests, je vous recommande d’avoir une page de test CSS unique incluant tous les modules CSS pris en charge pour tester les collisions et les cascades non intentionnelles.

Vous pouvez également utiliser une approche à plusieurs fichiers pour définir les règles CSS dans 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 minimiser) les fichiers CSS en un seul fichier de manière dynamique. Mais comme ces fichiers sont séparés et que leurs tests seraient séparés, vous introduisez la possibilité d'une apparence et d'une convivialité incohérentes sur les pages/sections. Ainsi, les tests deviennent plus difficiles.

À vous d’analyser les besoins spécifiques du client et d’équilibrer ces préoccupations en conséquence.

madr · Answer

Comme dit avant moi: Entrez dans OOCSS. Sass/Less/Compass est tentant, mais jusqu'à ce que Vanilla CSS soit utilisé correctement, Sass/Less/Compass ne fera qu'empirer les choses.

Tout d'abord, renseignez-vous sur l'efficacité des CSS. essayez Google Page Speed et lisez ce que Souders a écrit sur le css efficace.

Ensuite, entrez OOCSS.

Apprenez à travailler avec la cascade. (Après tout, nous l'appelons Cascading Stylesheets).
Apprenez à obtenir la granularité correcte (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 va révolutionner chaque élément de l'écriture CSS. Je suis totalement renouvelé et j'adore ça.

MISE À JOUR: SMACSS est similaire à OOCSS, mais plus facile à adapter en général.

Jack Kinsella · Answer

Les principes de base pour le CSS sensible, extrait de CSS Refactoring: Du append-only au CSS modulaire

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

N'utilisez jamais un identifiant HTML pour le style. toujours utiliser des classes . Les ID HTML, lorsqu'ils sont utilisés correctement, n'apparaissent qu'une seule fois dans la page entière, ce qui est l'opposé de la possibilité de réutilisation - l'un des produits les plus fondamentaux de l'ingénierie sensible. De plus, il est très difficile de remplacer les sélecteurs contenant des identifiants. Souvent, le seul moyen de neutraliser un identifiant HTML consiste à en créer un autre, ce qui entraîne la propagation des identifiants dans la base de code, à l’instar des codes nuisibles qu’ils contiennent. Mieux vaut laisser les identifiants HTML pour les crochets de test javascript ou d’intégration non modifiables.

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 démarquez des entreprises secondaires. Par exemple, nous avons commencé à vendre des notes de loi, mais nous avons récemment fait appel à des tuteurs. Nos anciennes classes CSS portaient des noms tels que ".download_document_box", un nom de classe qui a du sens quand on parle de documents numériques, mais qui ne confondre que lorsqu'il est appliqué au nouveau domaine des tuteurs privés. ".Pretty_callout_box" conviendrait mieux.

Évitez de nommer les classes CSS après des informations spécifiques sur la grille. Il existait (et il existe toujours) un terrible anti-motif dans les communautés CSS, dans lequel les concepteurs et les créateurs de frameworks CSS ( cough Twitter Bootstrap ) pense que "span-2" ou "cols-8" sont des noms raisonnables pour les classes CSS. Le but de CSS est de vous donner la possibilité de modifier votre conception sans affecter le balisage (beaucoup). Le codage en dur des tailles dans le code HTML contrecarre cet objectif, il est donc déconseillé dans tout projet censé durer plus longtemps qu'un week-end. Plus d'informations sur la manière dont nous avons évité les classes de grille plus tard.

Divisez votre code CSS entre plusieurs fichiers . Idéalement, vous scindiez tout en "composants"/"widgets", puis composiez des pages à partir de ces atomes de conception. De manière réaliste, vous remarquerez que certaines de vos pages de site Web ont des particularités (par exemple, une mise en page spéciale ou une galerie de photos bizarres figurant dans un seul article). Dans ces cas, vous pouvez créer un fichier lié à cette page spécifique, en effectuant uniquement la refactorisation dans un widget à part entière lorsqu'il devient évident que l'élément sera réutilisé ailleurs. C’est un compromis motivé par des préoccupations budgétaires concrètes.

Minimise l'imbrication. Introduisez de nouvelles classes au lieu d'imbriquer des sélecteurs. Le fait que SASS supprime la douleur liée à la répétition de sélecteurs lors de l'imbrication ne signifie pas que vous devez imbriquer cinq niveaux en profondeur. Ne sur-qualifiez jamais un sélecteur (par exemple, n'utilisez pas "ul.nav", où ".nav" pourrait effectuer 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 uniquement le nom de la classe et supprimez le sélecteur de base (par exemple, l'exemple précédent doit être ".highlight"). Les sélecteurs surqualifiés n’ajoutent aucune valeur.

Créez des styles pour les éléments HTML (par exemple, "h1") uniquement lors du style des composants de base qui doivent être cohérents dans l'ensemble de l'application. Évitez les sélecteurs larges tels que "en-tête ul "Parce qu'il est probable que vous deviez quand même les remplacer à certains endroits. Comme nous le répétons, la plupart du temps, vous souhaitez utiliser une classe spécifique et bien nommée chaque fois que vous souhaitez utiliser un style particulier.

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

Mitchel Sellers · Answer

Souvent, je verrai des personnes 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 il est facile de revenir plus tard et de trouver ce sur quoi vous travaillez.

Toni Leigh · Answer

Vous devriez regarder BEM.

Théorie

BEM est une tentative de fournir un ensemble d'instructions pour organiser et nommer les sélecteurs CSS afin de rendre les choses plus réutilisables et modulaires et d'éviter les conflits entre les sélecteurs du type qui conduit souvent à des problèmes de code spaghetti et de spécificité.

Lorsqu'il est utilisé correctement, il produit des effets très positifs.

Les styles font ce que vous attendez quand ils sont ajoutés à un élément
Les styles ne fuient pas et n'affectent 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 renverser

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 de l'interface utilisateur et contiennent des variables, telles que des couleurs et des "méthodes", telles que la façon dont les éléments internes sont gérés. Tandis qu'un OO programmeur hardcore pourrait rechigner à cette idée, en fait, les concepts appliqués apportent beaucoup des parties les plus agréables des OO, telles que la modularité, le couplage lâche et la cohésion étroite et une réutilisation sans contexte. Vous pouvez même créer une structure qui ressemble à un objet encapsulé en utilisant Sass et le & operato r.

Un article plus détaillé de Smashing Magazine peut être trouvé ici ; et un de Harry Roberts de CCS Wizardry (que toute personne impliquée dans les CSS devrait lire) est ici .

En pratique

J'ai utilisé cela plusieurs fois, en même temps que SMACSS et OOCSS, ce qui signifie que j'ai quelque chose à comparer. J'ai également travaillé dans de gros bazar, souvent de ma propre création inexpérimentée.

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 compte aussi un peu sur la cascade et la spécificité. Ici, le module BEM serait .primary-box et le .header constituerait le contexte d’un remplacement spécifique.

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

(Je fais de mon mieux pour rendre tout aussi générique et exempt de contexte, ce qui signifie qu'un bon projet est quasiment tout dans les modules réutilisables)

Un dernier point que je voudrais dire ici est que, même si votre projet semble 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 d’établir de bonnes bases, y compris les CSS
même un projet qui semble simple parce qu'il repose sur WordPress a peu de JavaScript peut encore être très complexe en CSS - OK, vous n'avez pas à coder côté serveur, alors cette partie est simple, mais le devant de la brochure comporte vingt modules et trois variantes: vous avez des fichiers CSS très complexes!

Composants Web

En 2015, nous commençons à nous intéresser aux composants Web. Je ne connais pas encore beaucoup de choses à ce sujet, mais ils cherchent à rassembler toutes les fonctionnalités frontales dans des modules autonomes, en essayant efficacement d'appliquer le type de principes de BEM au front-end dans son ensemble et de créer des composants dispersés mais totalement couplés. 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 aborderont certains des problèmes initiaux liés aux CSS que nous avons essayé de résoudre avec BEM, tout en rendant certaines autres architectures frontales plus saines.

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

Enfin

Je pense aussi qu’il s’agit d’un excellent guide des meilleures pratiques css modernes - conçu spécifiquement pour empêcher les grands projets css de se salir. J'essaie de suivre la plupart d'entre eux.

quinton · Answer

il y a de la bonne matière ici et certaines ont pris beaucoup de temps pour répondre à cette question, mais 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 je passerais à la fusion de tous vos fichiers css génériques. dans un seul fichier une fois déployé.

de cette façon, vous obtenez le meilleur des deux mondes, augmentez les performances (moins de requêtes HTTP sont demandées à partir du navigateur) et séparez les problèmes de code pendant le développement.

Iouri Goussev · Answer

Je vous recommande de regarder framework CSS "Compass Style" .