Conseils pour la structure CSS pour les sites Web d'entreprise (ou tout autre pour ce sujet)

CSS et HTML sont simples à comprendre. Cependant, il faut des années de pratique pour apprendre les meilleures approches architecturales lors de la création de sites Web (et d'applications) d'une manière qui les rend réutilisables, maintenables à l'avenir et satisfait les développeurs.

Qu'entend-on ici par architecture? C'est la structure du code CSS. La façon dont vous le séparez en fichiers, les règles derrière les noms de classe, la profondeur des sélecteurs, la façon dont il se cascades, ce qui est hérité, comment vous configurez les composants, les pages, les éléments et les modificateurs.

Appliquer les meilleures pratiques à tous ces composants de site Web avec des centaines de pages, différents types de contenu, des vues d'écran, des cas de bord, et en envisageant d'en ajouter d'autres et de modifier ceux existants est la partie la plus difficile.

Construire avec des composants, pas des pages

C'est l'une des principales parties à considérer. Vous ne devez pas créer de style en fonction de la page sur laquelle vous vous trouvez. Ne faites pas de styles .homepage… {}. Si votre page comporte une section, stylisez la section. Avec cela, vous pouvez également le réutiliser sur d'autres pages. Si vous avez un bouton, donnez-lui un style comme .button {} et réutilisez-le ailleurs. Il est valable pour toutes les vues.

Il s'agit du conseil le plus courant et de l'approche la plus performante (à ce jour) que vous pouvez utiliser.

Maintenant, comment gérez-vous les différences spécifiques aux pages? Parce que c'est la raison la plus courante de styliser par page? Eh bien, il existe quelques approches:

Utilisez des modificateurs.

Dans «BEM», le «M» signifie Modifier. C'est l'aspect .block__child – modificateur. Même si vous n'utilisez pas BEM, les modificateurs existent de toute façon. S'il existe une variante d'un composant ou d'une section, ajoutez-lui un modificateur.

Idéalement, le concepteur doit être réfléchi et limiter les variations au minimum pour garder le code propre, mais vous ne devriez pas avoir peur d'en ajouter plus. Les variations devraient idéalement remplacer simplement quelques propriétés et fonctionner avec le même balisage. C'est un bon moyen d'aborder les composants dans la phase HTML - ajoutez les balises dont vous aurez besoin et maintenez-les cohérentes sur le site. N'en ajoutez pas de nouveaux à cause d'une classe de modificateurs.

Style des composants pour enfants.

L'autre approche est le style basé sur le contexte. Un bouton est toujours un bouton, il a sa classe .button et tout, mais vous pouvez toujours l'ajuster s'il fait partie d'un autre composant. Ce n'est généralement pas une bonne idée car cela crée des incohérences, mais c'est aussi un cas d'utilisation assez réaliste. Sinon, vous vous retrouveriez avec 20 modificateurs aux noms étranges.

Les styles contextuels sont lorsque vous stylisez un composant uniquement s'il s'agit d'un enfant d'un autre. Prenons une fiche d'article par exemple. Il a ses styles par défaut. Mais si elle fait partie d'une section colorée avec du texte sur le côté, la conception nécessite que la carte soit entourée de quelques autres éléments (comme des formes animées, etc.).

Dans ce cas, vous stylisez avec le sélecteur .parent .card {}. Vous n'aurez qu'à écraser quelques propriétés comme vous le feriez avec un modificateur. Lorsque vous faites cela, la carte elle-même n'ajoute pas plus de complexité à ses styles, mais elle se comportera toujours correctement sur ce cas particulier.

Lorsque vous pensez à cela, vous pouvez également voir comment il peut être appliqué sur une base «par page». S'il y a des cas de bord étranges dans la conception et qu'il y a quelques différences mineures par rapport aux vues standard des composants (et à la façon dont ils interagissent tous ensemble), alors vous pouvez le styliser avec le sélecteur .homepage {}. N'oubliez pas de l'utiliser avec parcimonie. D'après notre expérience, ces styles dépassent rarement quelques lignes de code.

Remarque importante à ajouter: les styles contextuels ne sont PAS une bonne pratique en général. Idéalement, vous ne devriez même pas en avoir besoin. La plupart du temps, vous auriez des modificateurs qui devraient faire le travail assez bien. Même si c'est réaliste dans certaines versions, plonger trop profondément dans un bon code abstrait avec des règles strictes peut être trop coûteux.

Travailler en sections

La plupart des sites Web d'entreprise (ainsi que de nombreux autres d'ailleurs) séparent le contenu en sections. Chaque section est un composant à part entière avec une classe de modificateurs qui définit les différentes propriétés. Une suggestion pour aller avec la structure des classes serait:

• section.section-container - cela pourrait être le «nom du composant» si vous le souhaitez, qui contient les bourrages / marges cohérents ou tout ce qui est nécessaire.
• section.section-border-top - est un modificateur. Cela n'utilise pas BEM, mais vous pouvez le «traduire» en section-container – border si nécessaire.
• section.section-welcome - serait le nom de la section.

Ici encore, la convention de dénomination n'est pas pertinente. Avec de telles sections, vous auriez la liberté d'ajuster les styles aux composants réutilisables dans les cas de bord créés par la conception (que ce soit en raison d'incohérences à suivre ou simplement de vues plus compliquées).

Séparation des fichiers

Vous utiliseriez très probablement Sass ou un autre préprocesseur similaire. En termes de séparation des fichiers, il existe de nombreuses approches, mais celle que nous adoptons suit la structure générale suivante:

• Général - Le général consiste généralement en un code de configuration tel que le fonctionnement d'une grille, des styles aux balises HTML, des réinitialisations / normalisateurs, des styles spécifiques au CMS et autres.
• Pages - Les styles de page comme expliqué ci-dessus. Idéalement, vous devriez garder très peu de code ici.
• Composants - Le cœur de la construction - les différents composants résident ici. Une astuce est que vous pouvez avoir des «éléments» ou «divers» qui rangeraient de plus petits morceaux de composants dans un seul fichier au lieu de 80 fichiers. Les plus gros devraient bien sûr être placés dans des fichiers séparés.
• Disposition - Styles globaux, par exemple, sur l'en-tête, le pied de page, puis les présentations de page, les modificateurs de votre grille, etc.
• Plugins - Tout ce qui est externe généré à partir d'un plugin, d'une extension ou autre. C'est bien de les séparer car vous pouvez ensuite les réutiliser dans d'autres projets.

Gardez les sélecteurs propres

Un bon signe de code propre est sa simplicité. Pas de propriétés étranges, tout a son but, il y a une faible indentation. Les sélecteurs «à la recherche intelligente» lorsqu'ils ne sont pas nécessaires ne rendent pas votre code «cool». Si vous pouvez remplacer quelque chose comme #container> .row div [rel = ”something”] par .rel-something (imaginez que c'est un nom de classe significatif), alors vous devriez simplement mettre à jour un peu le balisage. Le but est de simplifier les choses.

Gardez les indentations basses. Vous avez rarement besoin d'aller plus de trois niveaux. Voyons par exemple une classe .entry:

.entry {...}
.entry-title {...}

Voyez qu'il n'est pas vraiment nécessaire d'indenter .entry-title à l'intérieur de .entry. Plus tard, lorsque vous ajoutez un modificateur dans le fichier, vous pouvez avoir .entry-modifier {} et .entry-modifier .entry-title {}

Avec cette approche, l'écrasement des styles à l'avenir est beaucoup plus facile. Jetons un coup d'œil à un autre exemple courant: vous avez le balisage nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Maintenant, pour styliser, tout ce dont vous avez besoin est:

.site-nav {} - composant 1

.list-menu {} - composant 2
.list-menu .list-item {}
.list-menu a {}

Si vous aviez plus de composants à l'intérieur, comme des listes déroulantes supplémentaires, vous pouvez les imbriquer directement dans .list-menu. Vous n'avez pas besoin d'écrire .site-nav .list-menu .list-item .dropdown {} (4 niveaux de profondeur) lorsque vous pouvez avoir deux niveaux de .list-menu .dropdown {}

Écrire plus de noms de classe abstraits pour les modificateurs

Celui-ci va pour la maintenabilité. Un exemple courant que vous trouveriez dans des articles similaires serait de ne pas définir une variable de couleur sur $ red, mais plutôt de la définir sur $ primary ou $ secondary.

La raison en est que lorsqu'un changement est nécessaire sur toute la ligne, la variable $ red produira du bleu. Il est beaucoup plus logique que vous souhaitiez changer votre couleur principale , pas votre couleur rouge , non?

Il en irait de même pour d'autres types de couleurs et de propriétés. Disons que vous avez des lignes séparant certains contenus (comme la balise <hr>). Vous appelez ce .line-dash parce qu'il est en pointillés. Cela a du sens. Mais alors un changement survient et il doit être pointé. Allez-vous le renommer en .line-dotted? Ce n'est pas un modificateur, c'est le composant. Au lieu de cela, vous pouvez le nommer comme .line-separator. Et puis si vous voulez être précis, vous pouvez ajouter un modificateur pour .dotted ou .dashed. Ce type de dénomination est souvent ce qui prend le plus de temps lors de la création d'un site.

En résumé

Il existe d'innombrables bonnes et mauvaises pratiques. Une façon d'obtenir de meilleurs résultats est de définir des règles et de les suivre. Il est difficile de trouver de telles règles, donc une bonne suggestion serait de naviguer sur le Web et d'essayer de rassembler toutes les informations possibles sur l'architecture telles que les conventions de nommage, les bonnes pratiques, comment écrire du code maintenable et plus encore.

Produire un bon code prend beaucoup de temps et des centaines de milliers de lignes de code. Tout en faisant tout cela, demandez-vous toujours «Est-ce que cette échelle?», «Puis-je la réutiliser?», «Ai-je trop écrasé?», «Est-ce que cela a du sens de l'appeler comme ça? Plus vous faites cela, plus vos décisions deviendront optimales et plus votre vitesse de travail s'améliorera.

Un investissement dans de bons fondamentaux se traduira par moins de va-et-vient sur vos projets et tout changement futur qui doit se produire sera beaucoup plus facile à mettre en œuvre.