CSS moderno: escribe un código mejor, más limpio y escalable

1. Introduction: Comme beaucoup de gens, je suis entré sur le web complètement par accident. J' ai cru que j'allais être un graphiste malheureux pendant de nombreuses années, et je me sentais beaucoup plus amoureux du développement que jamais du design. Hey, je suis Harry, je suis un consultant web développeur et ingénieur performance du Royaume-Uni. Depuis six ans, je prends la parole à de nombreux événements. Une grande partie de cela est IT CSS ou Inverted Triangle CSS, et c'est ce que nous allons apprendre aujourd'hui. IT CSS est une méthodologie, une façon de penser à CSS. Il vous aidera à développer et à mettre à l'échelle des projets sur une très longue période de temps. Le triangle inversé est une vue d'ensemble très schématique d'un projet CSS entier. La raison pour laquelle nous avons un triangle est que chacun des trois côtés représente l'un des principaux locataires de CSS Triangle inversé. Peu importe si vous utilisez SaaS, LaaS, ou Vanilla CSS, ou Host CSS ou même une solution CSS dans JS, IT CSS vous entraînera exactement où vous devez placer chaque composant différent de la ligne zéro à la ligne 15 000 de votre projet. Donc, les premières leçons de ce cours, peut-être tout à fait théoriques, beaucoup de diagrammes, beaucoup de choses de dessin, et vraiment nous donner la tête autour de la façon dont le CSS informatique fonctionne, théoriquement. Une fois que nous avons couvert tout cela, nous allons plonger directement dans une base de code et regarder des exemples de la façon dont IT CSS se réunit sur le système de fichiers comme une ligne de code. La bonne nouvelle est que vous n'avez pas besoin d'être un expert en CSS pour commencer à utiliser IT CSS. Si vous avez une compréhension simple des fondamentaux de CSS, vous pouvez commencer à utiliser IT CSS dans les projets immédiatement. Je suis incroyablement excité de commencer à vous enseigner tout sur IT CSS. Alors commençons. 2. Les problèmes avec le CSS: Afin de bien comprendre l'ITCSS, il est important que nous examinions les problèmes que nous essayons de résoudre. CSS est un langage développé il y a plus de 20 ans. Nous utilisons toujours pour construire de mauvaises applications aujourd'hui. Ce n'est pas un problème en soi, mais certains des problèmes qui empêchent à grande échelle sont des choses que nous devons aborder. Par exemple, le fait que tout fonctionne globalement signifie que toute règle pourrait potentiellement hériter d'une autre ou transmettre ses styles à autre chose. Cela doit être géré très soigneusement. CSS est également incroyablement dépendant de l'ordre de la source. En gros, ce qui est écrit en dernier est ce qui sera appliqué. Cela signifie que nous devons être de garder un œil de très près sur l'ordre dans lequel nous structurons et construisons notre base de code. Cependant, ajoutez à cela le fait que nous avons une spécificité. Nous pouvons inverser complètement cette logique de toute façon et sélecteurs avec une spécificité plus élevée que d'autres, peuvent remplacer les choses de manière quelque peu inattendue. Nous pouvons tous ces pièges potentiels. Nous devons concevoir un système de gestion CSS, qui peut réellement formaliser et structurer ces fonctionnalités d'une manière qui fonctionne pour nous plutôt que contre nous. Cependant, il serait complètement inapproprié et injuste de tout blâmer sur CSS. Le fait que CSS a résisté à l'épreuve du temps pendant plus de deux décennies, montre que potentiellement il y a quelque chose que nous, en tant que développeurs, nous nous trompons aussi. Les développeurs ont de nombreux styles de codage différents. Un développeur pourrait écrire du code qui fonctionne exactement de la même manière que quelqu'un d'autre, mais semble très différent. Peut-être, nous devons gérer cela. Donc, nous avons une façon unifiée de travailler au sein d'une équipe. Les développeurs sont également réputés mauvais dans l'écriture de la documentation. Je ne pense pas avoir jamais travaillé sur un projet qui avait juste le bon montant. Et si nous pouvions faire notre documentation de code ? Si nous pouvons commencer à travailler sur une méthodologie partagée, peut-être pourrions-nous construire un projet sans avoir besoin de rames et de rames de documentation. énorme problème que les équipes plutôt que les individus présents, est que CSS est probablement le seul langage que chaque membre d'une équipe de développement écrira. Je n'ai jamais écrit une ligne de Node.js. Je n'écris pas de MySQL. Mais chaque personne avec qui j'ai travaillé a écrit au moins quelques CSS. Cette diversité et ces compétences contribuent à une seule langue signifie que nous ne pouvons pas garantir que tout le monde en sait autant que la prochaine personne. Si nous pouvions concevoir une méthodologie qui supprime le stress et la douleur, nous pourrions obtenir des non-experts qui contribuent à la CSS d'une manière non préjudiciable. En tenant compte de tout cela, en étant sympathique à façon dont les équipes travaillent et en tenant compte du fonctionnement de la CSS, nous avons besoin d'un cadre et d'une façon de travailler qui aideront à résoudre ces problèmes. Ce cadre est ITCSS. Laisse plonger dedans. 3. Le CSS sans ITCSS: Donc, ce qui va commencer par est de le visualiser d'une manière très schématique, quoi pourrait ressembler un projet existant ou non ITCSS, et où les problèmes se produisent dans feuilles de style qui n'utilisent pas une méthodologie officielle telle que ITCSS. Donc, imaginez si vous voulez, que ce rectangle ici représente tout un projet CSS existant. Il s'agit d'un fichier CSS. Maintenant, cela pourrait être un fichier CSS réel d'un seul fichier monolithique, ou cela pourrait être le résultat de la compilation de beaucoup de fichiers SaaS différents dans un gros fichier. façon dont nous arrivons à ce point n'est pas vraiment importante pour l'instant. Imaginez juste que c'est votre projet CSS entier, et pour rendre les choses un peu plus faciles à comprendre, disons que nous avons la ligne zéro, jusqu'à la ligne 3000. Disons que c'est un joli petit projet. Maintenant, traditionnellement, la façon dont nous écririons normalement CSS, c'est que nous examinions le design que nous sommes sur le point de construire et nous identifions les premières fonctionnalités. Nous pourrions regarder la conception et voir bien, nous devons utiliser une réinitialisation CSS. Donc, j'ai mis ma réinitialisation CSS quelque part près du début parce que cela semble avoir du sens. Donc, nous commençons par mettre un échafaudage, peut-être une sorte de cadre remplissant CSS vers le début, puis regardons plus loin dans la conception et décidons que bien, la première chose dans un fichier Photoshop ou le fichier esquissé est un en-tête. Donc, j'ai mis mon en-tête CSS ici. Maintenant, nous construisons des feuilles de style autour d'un langage visuel ici. La structure d'un design. C' est une façon très courante d'écrire CSS, et pour la plupart, en particulier sur les petits projets, cela fonctionnera généralement. Au fur et à mesure qu'un projet commence à grandir, nous commencerons à rencontrer des problèmes. Ce que nous faisons ici, c'est que nous écrivons CSS dans un ordre très, très humain. C' est ainsi qu'un humain regarde CSS. Cependant, le problème que nous avons est qu'un navigateur ne se soucie pas de savoir si l'en-tête est la première chose dans un fichier photoshop ou non. Tout ce dont un navigateur se soucie est de la spécificité d'un sélecteur, de la portée de ce sélecteur, ce qui pourrait hériter de ce sélecteur. Donc, si nous commençons à écrire notre CSS d'une manière structurée très humaine, nous allons bientôt rencontrer des problèmes, où peut-être le premier bit de CSS fonctionne bien, et nous écrivons un autre morceau de CSS et cela fonctionne très bien. Nous écrivons à nouveau un troisième bit de CSS, ne rencontrant aucun problème. Tout d'un coup, nous pourrions écrire un quatrième bit de CSS mais pour une raison quelconque est remplacé par ce CSS ici. Cela pourrait être causé par les murs de spécificité, cela pourrait être causé par des sélecteurs se battant l'un l'autre, il pourrait être causé par un certain nombre de choses, mais sans tenir compte pleinement de notre architecture CSS en écrivant CSS dans ce que je considérerais comme une manière très humaine. Eh bien, pas vraiment très sympathique pour aider CSS fonctionne réellement ou comment le navigateur apprécierait de recevoir ce CSS. Maintenant, nous avons un problème. On a un problème ici où on voulait réparer quelque chose. Nous pourrions refactoriser ce morceau de CSS ranger et supprimer le problème, mais ce n'est généralement pas ce qu'un développeur ferait. Nous avons peut-être des contraintes de temps, échéances, mais ce que nous étions les plus susceptibles faire, c'est de pirater quelque chose pour le réparer. Donc, on pourrait finir par coller un important ici, faire quelque chose d'assez méchant. Une fois que nous aurons résolu ce problème, nous passons à autre chose. Le prochain bit de CSS fonctionne très bien. Le prochain bit de CSS fonctionne très bien. Le prochain bit de CSS est dépassé par ceci, et puis ce bit ici remplace ce bit ici. Donc, nous avons un problème plus loin dans la pile. Sur un grand projet, je peux presque garantir que chaque développeur a rencontré une situation comme celle-ci et que cette frustration réduit massivement la productivité. Une grande partie du temps est passé à vous peindre dans un coin, puis à essayer de le combattre, et généralement le problème ne fait qu'empirer. À moins que vous ne consacriez beaucoup de temps à refactoriser le CSS, vous allez continuer sur ce chemin, et sur une période de semaines, de mois, peut-être même d'années, le problème deviendra si mauvais que vous aurez besoin de complètement recommencer. Continuons. Écrivez un peu plus de CSS. C' est bien, c'est bien qui remplace ça, c'est une amende, très bien, qui est remplacé, est remplacé ici. Cette nature toujours ou constamment erratique, ce genre d'inefficacité est très répandu dans les grands projets, et c'est ainsi que les projets CSS commencent à se déchaîner hors de contrôle. Donc, après une période assez longue dans ce projet a mûri, nous constatons que toutes ces inefficacités se produisent assez fréquemment. Habituellement, vous identifierez ces frustrations de première main, alors que vous travaillez sur un projet, vous remarquerez que nous avons ces problèmes. Vous remarquerez que peut-être une fonctionnalité vieille de six mois, remplace une fonctionnalité que vous écrivez en ce moment. Une autre bonne façon, un moyen facile de les identifier dans le navigateur, est dans l'inspecteur chromes. Lorsque vous faites un clic droit et inspecter l'élément, si vous voyez beaucoup de CSS avec des lignes là-bas, beaucoup de strikethrough, cela représente une énorme inefficacité. Cela représente le CSS qui a été écrit à un moment donné, enregistré sur le disque, compilé dans une feuille de style, envoyé à un serveur Web, finalement envoyé à un utilisateur, envoyé à son navigateur, et il n'a jamais été utilisé. C' est dans les gains d'efficacité que nous écrasons constamment CSS qui a été écrit plusieurs mois auparavant. Maintenant, si ce diagramme ici représente la Phase 1 d'un projet CSS, c'est peut-être la construction initiale d'un projet, la série initiale d'entités d'un projet. Les problèmes s'aggravent encore lorsque nous commençons à ajouter nouvelles fonctionnalités distinctes ou de nouvelles phases distinctes. Donc, si cela représente la Phase 1, généralement, l'endroit où nous mettrions la Phase 2 d'un projet CSS est malheureusement, nous avons tendance à boucler sur la fin. C' est ainsi que CSS a généralement tendance à fonctionner. On a juste bousillé les choses à la fin. Phase trois, reste à la fin de ça. Donc, le problème se complique où non seulement le code à l'intérieur de chaque phase se bat contre lui-même, nous pourrions finir avec des phases entières du projet se disputant aussi. Maintenant, si vous regardez, nous avons fini avec ce phénomène étrange où notre CSS est en quelque sorte mis à la phase un sur le dessus, la phase deux, la phase trois, et cela me rappelle l'enregistrement fossile. Droit ? Vous avez des CSS crétacés ici, des CSS jurassiques ici. y a absolument aucune raison que je devrais être capable découper votre CSS et de le lire chronologiquement. n'y a aucune raison pour que votre projet CSS reflète votre feuille de route produit. Mais la plupart du temps, si nous n'avons pas de façon structurée de travailler, c'est exactement ce qui se passe. Je ne devrais pas être capable de comprendre qu'à cette date, vous avez publié cette fonctionnalité uniquement en regardant une feuille de styler-feuille. En utilisant IT CSS, nous pouvons prendre tous ces problèmes et réimaginer une structure dans laquelle cela disparaît. Ces problèmes que nous assistons ici, cela aurait pu rayé à travers ce saut très erratique autour de la nature que nous obtenons à l'intérieur du projet CSS, peuvent être causés par un certain nombre de choses. Spécificité mal gérée. Donc, l'utilisation de sélecteurs qui sont trop lourds, cela pourrait être causé par dessiner des choses dans un ordre inefficace ou un ordre peu pratique, ou cela pourrait être causé par la conception de choses ou l'écriture de code qui prend trop de stands et opinionisés trop tôt. triangle inversé CSS vise à prendre tous ces trois locataires principaux et à les formaliser formant chaque côté du triangle. 4. Les guerres de spécificité: Jetons donc un coup d'oeil à ce que le Triangle comprend réellement. Nous avons mentionné brièvement la spécificité. spécificité est la pondération inhérente d'un sélecteur, sa proéminente, sa capacité à remplacer d'autres sélecteurs dissemblables. spécificité est l'une des choses les plus difficiles à gérer sur un projet CSS à grande échelle. L' une des premières règles clés lors de l'écriture de CSS pour un grand projet est, toujours éviter l'utilisation du sélecteur d'id. Si vous voulez en savoir plus sur la raison pour laquelle nous avons interdit le sélecteur d'ID dans CSS, reportez-vous aux ressources. Ainsi, la spécificité est un énorme problème lors de l'écriture de CSS à grande échelle. Afin d'aider les équipes de développement à visualiser la spécificité de l'ensemble de leur projet, j'ai trouvé un concept de graphique de spécificité. Ce que le graphique de spécificité fera, c'est prendre le diagramme précédent, [inaudible] toute la feuille de style, et de tracer la spécificité de ses sélecteurs. C' est un simple graphique linéaire. Nous tracons la spécificité d'un sélecteur. Sur l'axe X, nous tracons le numéro de ligne à laquelle ce sélecteur apparaît. Maintenant, en commençant par un projet existant, peut-être commençons par le sélecteur d'étoiles. Le sélecteur d'étoile porte une valeur de spécificité de zéro. Donc, à la ligne 1 à la ligne 3 000, nous pourrions commencer par un sélecteur avec une valeur de spécificité de zéro. Dans un projet existant ou hérité, les chances sont très élevées que nous n'ayons pas réellement géré notre spécificité correctement. Cela pourrait conduire à un graphique de spécificité qui ressemble à ceci. Peut-être que nous commençons par un sélecteur d'étoiles, peut-être des sélecteurs d'éléments, quelqu'un a utilisé un ID, peut-être quelques classes parmi ici, et une classe imbriquée. Ce que nous verrons au fur et à mesure, c'est nous tracons les différents types de sélecteur et leurs spécificités relatives sur un graphique qui pourrait finir par ressembler à ceci. Il est important de noter à ce stade qu'il s'agit d'un modèle purement théorique. Ce n'est pas un graphique de spécificité réel d'un projet réel. Si vous souhaitez voir un vrai graphique de spécificité, référez-vous aux ressources. Il existe des outils disponibles qui prendront une feuille de style d'entrée et vous construiront un graphique précis. Pour l'instant, cependant, il suffit de voir cela comme un modèle mental pour aider à visualiser le problème de la spécificité mal gérée. Un projet existant ou hérité, sans sa spécificité correctement gérée, peut avoir un graphique qui ressemble à ceci. Comme vous pouvez le voir, il y a très peu de cohérence. Maintenant, le problème n'est pas nécessairement là, avec des spécificités élevées. Le problème existe lorsque nous voulons contribuer du code dans une zone de faible spécificité. Si nous voulons faire des modifications ou des ajouts ou ajouter une nouvelle fonctionnalité à cette partie particulière de la base de code, nous avons la crainte que ce sélecteur ici puisse nous remplacer par inadvertance. Si c'est le cas, nous pouvons avoir à introduire ici quelque chose comme un sélecteur important ou imbriqué ou un autre type de hack pour augmenter artificiellement la spécificité de ce sélecteur pour remplacer celui-ci. Cela nous amène à son tour un autre problème parce que si cette partie de la base de code doit maintenant remplacer celle-ci ? On est coincés dans cette rue à sens unique, où on ne peut pas se retirer à tout moment, on ne peut pas simplement se retirer de ce modèle. Nous sommes dans ce qu'on appelle les guerres de spécificité, où nous devons continuer à nous battre exactement sur la même voie, rendant le reste du projet progressivement pire. C' est ce que nous appelons généralement un mauvais graphique de spécificité. Donc, sur un projet de la vie réelle, le genre de forme de graphique que nous recherchons est constamment à la hausse. Autrement dit, nous voulons que la spécificité de l'ensemble du projet augmente progressivement à mesure que nous passons de la première ligne à la fin du projet, dans notre cas, un projet relativement petit de seulement 3000 lignes. Si on devait visualiser ça, ça ressemblerait un peu à ça. Un graphique de spécificité qui évolue constamment vers le haut a l'avantage immédiat du fait que tout ce qui est défini plus tard dans le projet remplacera automatiquement tout ce qui a été défini précédemment, en raison de son emplacement. Le résultat pratique de ceci est qu'une fonctionnalité définie, par exemple, ici, devrait automatiquement remplacer tout ce qui a été défini précédemment en fonction de l'endroit où elle vit. La même chose peut être dite d'une fonctionnalité ajoutée, par exemple, ici. Cela commence immédiatement à supprimer le problème des fonctionnalités anciennes ou existantes ou même héritées qui remplacent les nouveaux travaux. Maintenant que nous sommes arrivés à la forme du graphique de spécificité théorique, sain et bon, nous pouvons commencer à le transformer en quelque chose de plus tangible et plus pratique. Nous pouvons commencer à prendre des tranches de cette base de code théorique et commencer à créer des répertoires sur le système de fichiers qui abriteront nos différents types de CSS. La première tranche ou couche de notre triangle inversé est dédiée à un type de reset-type assez générique de styles, choses comme normalize.css ou votre réinitialisation CSS, tout type de taille globale de boîte, tout ce qui est très largement disponible au projet mais a une très, très faible spécificité. Ce répertoire abritera ce type de code et est nommé générique. En règle générale, nous trouverions que la couche générique serait identique dans presque tous les projets sur lesquels vous travaillez. Vous avez probablement utilisé exactement le même normalize.css dans différents projets. Vous avez probablement utilisé exactement le même reset.css dans différents projets. Cela signifie que cette couche est très copiée et collable et peut être déployée sur de nombreux projets ou produits différents. Après la couche générique, nous commençons à augmenter notre spécificité. Nous entrons dans ce qui est connu sous le nom de couche d'éléments. La couche d'éléments, de façon prévisible, contient n'importe quel CSS dédié au style des éléments HTML. Par exemple, à quoi ressemble un élément sans classe dessus ? À quoi ressemblerait un élément h1 sans une classe dessus ? Nous avons légèrement augmenté la spécificité, et nous avons commencé à modifier la fonction du CSS pour commencer à ajouter des styles de conception. Mais c'est encore une très faible spécificité et une couche assez large. Une bonne règle empirique lorsque vous pensez la couche d'éléments est d'imaginer à quoi ressemblerait votre site s'il n'avait aucune classe ou ID nulle part en HTML. Comment le CSS ferait un simple h1 et un paragraphe ? Comment CSS fait-il un lien simple une liste non ordonnée ? Au-delà de la couche d'éléments, nous entrons dans ce qu'on appelle la couche d'objets. La couche d'objets est la première couche dans laquelle nous sommes autorisés à introduire la spécificité au niveau de la classe. Donc, alors que la couche générique commence avec quelque chose d'aussi faible spécificité que le sélecteur d'étoiles, la couche d'éléments ne traite que des sélecteurs d'éléments HTML. La couche d'objets est autorisée à commencer à traiter avec la spécificité au niveau de la classe. En CSS, un objet est un modèle de conception structurelle. Il provient d'une école de pensée nommée Object-Oriented CSS, qui a été développée par Nicole Sullivan. CSS orienté objet pourrait être un cours Skillshare en soi, alors veuillez vous référer aux ressources pour un apprentissage supplémentaire. Mais pour l'instant, tout ce que vous devez savoir, c'est que la couche d'objets est la première couche qui introduit la spécificité au niveau de la classe, et elle traite des modèles de conception structurelle. Ce sont des choses comme des systèmes de grille. La couche suivante que nous rencontrons dans le triangle inversé est connue sous le nom de couche de composants. Pour moi, la couche de composants est de loin la plus importante. La couche de composants est la chose qui contient la majorité de ce que nous connaîtrons comme le site Web. Les composants sont des choses comme des boutons ou des éléments de navigation ou des carousels. La couche de composants contient la chose que l'utilisateur verrait et interagirait avec. Vous devriez considérer les couches précédentes comme très architecturales. Ce sont les choses que l'utilisateur est très peu susceptible d'être au courant. L' utilisateur ne se soucie pas vraiment si vous utilisez normalize.css, l'utilisateur ne se soucie pas du système de grille que vous utilisez. trois couches précédentes sont l'endroit où nous traitons la plupart des problèmes architecturaux, et la couche de composants est l'endroit où nous commençons à réaliser l'encapsulation. La couche de composants serait composée de fichiers uniques qui contrôleraient peut-être un carrousel ou une liste déroulante ou un bouton. Proportionnellement, la couche de composants constitue la plus grande partie du projet, car la plupart de votre site Web seraient des composants. Cela signifie que vous feriez la plupart des changements et ajouts à votre projet dans cette partie de la base de code. Très important, par conséquent, nous encapsulons très bien le code ici. La dernière des couches ITCSS par défaut est connue sous le nom de couche utilitaires. Ce que vous remarquerez ici, c'est cette énorme pointe vers la fin. C' est parce que la couche utilitaires est réservée à tous les CSS méchants dont vous ne voulez pas vraiment parler. La couche d'utilitaires est l'endroit où vous pouvez déposer des choses comme des hacks ou vos feuilles de style IE7. Ici, vous pouvez également vous en sortir avec l'utilisation importante. Maintenant, si nous prenons du recul et regardons ce graphique terminé, nous pouvons commencer à voir un résultat plus tangible et significatif. Nous pouvons voir qu'à mesure que nous progressons de la ligne 1 à la ligne 3 000 de notre projet, la spécificité de notre CSS ne cesse d'augmenter. Au fur et à mesure de cette augmentation de la spécificité, nous commençons à retirer des tranches verticales du projet et classer notre CSS autour de certaines fonctions. 5. Les trois côtés de l'ITCSS: Maintenant, vous commencez probablement à vous demander comment nous avons réussi à aller aussi loin et même pas encore vu un triangle. Eh bien, nous allons voir exactement où ça s'insère. Nous venons d'apprendre sur les graphiques de spécificité et beaucoup de détails, le triangle de l'onduleur travaille sur trois principes fondamentaux et le plus important de ceux-ci est la spécificité. Maintenant, ce diagramme représente une fois de plus l'intégralité de votre projet CSS, qu'il s'agisse d'un seul fichier CSS ou que ce soit le résultat de nombreux fichiers SAS compilés dans une feuille de style résultante, ce triangle représente tout cela mis ensemble. Donc, encore une fois, nous commençons la ligne zéro et nous descendons à la ligne 3000. Chaque bord du triangle représente l'un des trois principes fondamentaux. Le premier étant la spécificité. La spécificité augmentera toujours au fur et à mesure que nous avançons dans le projet, de la ligne zéro à la ligne 3000. Notre spécificité ne devrait jamais augmenter. Le deuxième principe fondamental qui sous-tend l'ITCSS est un principe appelé explicitness. Explicitness regarde l'idée de la façon dont un morceau de design pourrait être opiniâtre. Par exemple, si un seul bouton sur l'ensemble du site Web doit avoir un arrière-plan rouge, vous n'appliquez pas cet arrière-plan rouge à chaque élément A, vous attendez jusqu'à plus tard dans le projet pour identifier ce bouton et l'appliquer là. Beaucoup des raisons pour lesquelles le projet CSS commence à mal tourner et à commencer à s'effondrer, c'est parce que les gens ont tendance à concevoir trop tôt et doivent ensuite passer le reste de leur projet à annuler cela. L' explicité force une certaine retenue et fait que les développeurs optent uniquement pour des changements de conception supplémentaires lorsqu'ils sont nécessaires. Le troisième et dernier principe directeur de base derrière ITCSS forme le dernier côté du triangle et rassemble tout, ce principe est connu sous le nom de portée. Maintenant, alors que la spécificité et l'explicité augmentent à mesure que nous traversons le projet, portée diminuera en fait. Reach traite de la partie de la page ou du composant ou même de l'ensemble du site Web qu'un sélecteur spécifique est capable d'affecter. Un sélecteur de portée très éloignée, c'est comme si le sélecteur d'étoile pouvait affecter l'ensemble du DOM. Il a également une très faible spécificité. Inversement, une seule classe ne peut affecter qu'un seul nœud DOM à la fois, le nœud DOM auquel est attaché, et les classes ont également une spécificité beaucoup plus élevée. La portée diminue à mesure que nous descendons le triangle et c'est ce qui fait un triangle du tout. Sans portée, ce serait le carré inversé, qui, je suppose, est juste un carré et les carrés ne vendent pas d'ateliers. Reach rassemble l'ensemble du triangle et diminue la quantité de la page ou du composant d'un DOM que nous pouvons toucher à tout moment. Donc, comme c'est mon intention, tout cela est très haut niveau. Ce que je vais faire est de griffonner rapidement un exemple de sélecteurs à côté du triangle pour vous montrer quel type de code vous pourriez vous attendre à trouver où. Je l'ai déjà mentionné est le sélecteur d'étoiles, qui porte une valeur de spécificité exactement zéro. Le sélecteur d'étoiles peut affecter chaque nœud DOM sur une page, vache est très faible spécificité, et devrait donc également être très explicite. Vous ne voudriez pas appliquer la boule de poids de police au sélecteur d'étoiles. En progressant plus loin, nous pouvons trouver peut-être un sélecteur d'élément A. L' élément A a une spécificité plus élevée qu' un sélecteur d'étoile et ne peut donc affecter qu'un peu moins du DOM, seul chaque élément d'ancrage peut être stylé. En progressant plus loin, nous avons obtenu un style de conception plus explicite, peut-être que nous ne créons pas un bouton. Donc, un bouton est une explicité croissante. Une augmentation de l'explicité entraîne une augmentation naturelle la spécificité parce que nous devrions utiliser un sélecteur comme .button. Ce que vous avez tendance à trouver, c'est que la spécificité et l'explicité sont relativement égales. Tout ce qui a une spécificité de ceci aurait une explicité correspondante. Vous ne voudriez pas appliquer le style de conception d'un bouton la spécificité du sélecteur d'étoile, ce qui serait très préjudiciable. Imaginons une seconde que nous avons un type de bouton spécifique, peut-être un bouton sur lequel un utilisateur ne peut pas cliquer parce qu'il n'a pas saisi une adresse e-mail correcte. On aurait besoin d'un autre sélecteur pour ça. Maintenant, notre style de conception est devenu plus explicite parce que ce n'est pas seulement un bouton, c'est une sorte de bouton qui ne peut pas être utilisé. Cette augmentation de l'explicité peut nécessiter une augmentation de la spécificité. Donc, nous pourrions avoir un sélecteur comme. désactivé, ce qui indique un élément qui ne peut pas être utilisé. Prenant notre spécificité et notre précision, nous arrivons naturellement à la portée de ce sélecteur. La classe de désactivation ne serait appliquée qu'à un bouton est désactivé à un moment donné, donc sa portée est très petite. Si nous devons regarder l'élément A, qui pourrait être supérieur à 100 liens sur une page, cela signifie qu'il utilise un sélecteur, qui a une spécificité relativement faible, signifie également que parce qu'il pourrait y avoir 100 liens sur une page, nous ne pouvons pas leur donner un style de conception trop opiniâtre et comme il pourrait y avoir plus de 100 liens sur une page, la portée de ce bouton est en fait très élevée. Voici comment les trois paramètres clés, les trois principes fondamentaux, jouent tous les uns dans les autres. Normalement, ce que vous trouverez est que si vous obéissez à deux des trois principes, vous obtenez le troisième élaboré gratuitement. Chaque fois que vous avez besoin d'ajouter du code à un projet, demandez-vous, « Quel est le style de conception explicite ou opiniâtre ? » S' il s'agit d'un style de conception assez opinionisé, vous auriez besoin d'un sélecteur d'opinion équivalente qui apportera donc une spécificité. En vertu d'un style de conception assez explicite et d'une grande spécificité, vous allez facilement obtenir les riches travaillé pour vous. Pour développer brièvement la portée et ce que cela signifie pour la forme de notre projet, réimaginons rapidement le triangle comme forme réelle de cône plutôt qu'un triangle plat. Cette forme d'entonnoir représente maintenant la façon dont les sélecteurs au fur et à mesure que vous passez de la ligne zéro à la ligne 3 000 de votre projet affectent de moins en moins le DOM à la fois. Donc maintenant, ce que votre recherche est chaque couche est responsable style de moins en moins de la page au fur et à mesure que vous progressez. La première couche cible presque tout, et progressivement moins, et moins, et moins avant d'atteindre le bas du triangle ou maintenant, je suppose que le cône inversé, et votre affectant avec précision nœuds DOM simples à la fois. Une analogie utile pour tout ce flux de travail est si vous deviez imaginer un sculpteur qui fait une statue. Un sculpteur peut s'approcher d'une carrière et demander un grand bloc de marbre. Maintenant, ce que la carrière ferait peut-être, c'est de faire sauter ce morceau de marbre sur le côté de la paroi rocheuse, et de le ramener au moulin à pierre, et le moulin à pierre prendra ce gros morceau de roche, et en fera une belle cube utilisable. Puis, la possibilité d'emmener ce morceau de roche au studio, et d'obtenir un gros marteau et un gros ciseau, et a fait grossièrement la forme d'une personne. Après avoir fait cela, ils auront un marteau plus petit et un ciseau plus petit, et commenceront à mettre des détails comme des doigts. Ce qui serait une façon très inhabituelle de travailler, c'est si cette sculpture vient de prendre un gros bloc de marbre à peu près puis-je juste exploser hors mon rockface et de la mode juste le doigt parfait qui sort de la partie supérieure de celui-ci. Ce que j'essaie de faire ici est exactement la même chose avec CSS, couper des traits larges tôt dans un projet pour couvrir peut-être 50 pour cent du levage lourd. Ensuite, le bit suivant couvre les 10 pour cent suivants, puis 5 pour cent jusqu'à ce que nous obtenions ces petits et petits bits de travail ciblant de moins en moins de nœuds DOM à la fois. Travailler de cette façon nous permet de rester ciblés et de garder les choses bien gérées au fur et à mesure que nous progressons de plus en plus dans le projet. Donc, nous avons juste regardé beaucoup de diagrammes juste là, nous ne regardons pas une seule ligne de code. Passons maintenant à l'ordinateur. Voyez comment ces choses se réunissent dans un projet, sur le système de fichiers réel en utilisant le CSS réel. 6. L'ITCSS en pratique: Donc, nous avons passé un tas de temps là-bas à regarder des diagrammes très conceptuels. Nous n'avons pas regardé une seule ligne de code. Donc, ce que je veux faire maintenant est de plonger dans un exemple de projet que j'ai construit. L' exemple de projet s'appelle Discover. C' est une sorte de site Web de voyage simulé et il a un excellent référentiel auquel vous avez un accès complet, alors assurez-vous de vérifier les ressources pour cela. Il est également hébergé sur l'URL LINE, sorte que vous pouvez voir exactement ce que nous construisons. Mais jetons un oeil, c'est un petit type de projet composé qui est construit en utilisant ITCSS. La première chose que je veux vous montrer est à quoi cela ressemble sur le système de fichiers, quoi cela ressemble réellement dans le Finder. Maintenant, c'est un très petit projet parce qu'il a été inventé purement par exemple, donc vous ne verrez rien de complexe comme importe quelle sorte de tâche ou on a des pipelines de construction, quelque chose comme ça. Ici, nous pouvons commencer à voir les étoffes du triangle inversé. La première chose que vous remarquerez est que nous avons un fichier principal .scss, c'est notre point d'entrée unique. Donc, ce fichier est responsable de l'importation de tous les autres aspects du projet CSS dans leur ordre respectif selon le triangle inversé. Ensuite, vous verrez que chaque couche du triangle a un répertoire correspondant. Maintenant, c'est complètement facultatif. L' une des choses clés de ITCSS est qu'il laisse beaucoup de ces décisions au développeur. J' avais l'habitude d'avoir une configuration où je n'avais pas de répertoire pour chaque type de fichier CSS. Je viens d'avoir une structure de répertoire plat mais j'ai réalisé qu'après un certain temps cela devient vraiment difficile à gérer, donc je me déplace vers une structure plus comme celle-ci, dans laquelle nous pouvons voir que chaque type de sélecteur CSS, chaque type de dans un triangle possède son propre répertoire correspondant. J' ai regroupé tous les fichiers de chaque couche dans ce répertoire qui est nommé d'après moi, mais ce que je fais aussi est que j'ai nommé chacun de mes fichiers layer.file.scss. Donc, ici, vous verrez éléments.headings.css. Ici, nous pourrions voir objects.layout.scss. Avoir le nom de la couche à l'intérieur du nom du fichier rend très facile comprendre quelle partie le projet sur lequel je travaille à un moment donné. Mais encore une fois, cela dépend complètement de la préférence des développeurs. En plus de regrouper chaque type de fichier dans son répertoire correspondant, j'aime aussi nommer chaque fichier après la couche à laquelle il se rapporte. Donc, ce que vous pouvez voir ici est components.avatar.scss ou dans ce fichier ou c'est le dossier ici, nous avons objects.layout.scss. La raison pour laquelle j'aime faire cela, c'est qu'il est agréable de voir juste à partir du nom de fichier seul, sur quelle partie du projet je travaille. Si j'ai objects.layout.scss ouvert dans mon éditeur de texte, je sais exactement à quelle partie du projet je contribue. Maintenant, jetons un oeil à notre main.scss. C' est le point d'entrée principal. C' est le fichier source unique qui ferme tout le reste du projet et c' est ce fichier source qui produit main.scss plus tard. En regardant main.scss dans mon éditeur de texte, la première chose que vous remarquerez est cette table des matières. Encore une fois, c'est complètement facultatif, c'est la préférence du développeur. Mais j'aime maintenir une table des matières assez manuelle en haut de mon point d'entrée principal. Ce que cela me permet de faire est d'écrire en termes humains exactement ce qui est contenu dans le projet. Ce que vous trouvez souvent, c'est que les projets deviennent plus grands et vieillissent, beaucoup de gens ne connaissent pas le genre de CSS qui existe dans ce répertoire CSS. Ils ne savent pas quelles fonctionnalités existent déjà, ce qui a déjà été construit et ainsi de suite. Tout en conservant cette table des matières assez manuelle mais très lisible par l'homme, les développeurs sont toujours informés de ce qui leur est disponible. Passant à partir d'une table des matières, nous commencerons à voir mes directives @import. Donc, ce que vous verrez ici est mon importation pour les couches de paramètres et d'outils. Ce sont purement pré-processus de couches. Cela contient des paramètres globaux pour mon projet tels que des échelles typographiques ou des palettes de couleurs. La couche d'outils contient des éléments à voir avec les mixages ou les fonctions nécessaires au projet. Permettez-moi de passer aux couches que nous avons vues précédemment. Ce sont des choses que nous avons dessinées dans nos diagrammes. Si vous avez remarqué la taille relative de chaque couche, vous pouvez commencer à comprendre d'où provient la majeure partie du projet. Par exemple ici, la couche générique est plutôt petite. Nous n'avons pas vraiment beaucoup ici, nous avons notre taille globale de boîte, certains normalisent et réinitialisent types de styles et certains styles partagés aussi. Mais regardons dans la couche d'éléments. Nous pouvons voir que nous avons encore quelques fichiers ici, commencent à devenir un peu plus gros. C' est là que nous signons des choses comme des en-têtes, des liens et des listes. Ce sont les éléments html qui composent notre page. Au-delà de cela, nous passons à notre couche d'objets. La couche d'objets est la première couche dans laquelle nous sommes autorisés à introduire des classes. Encore une fois, cela est légèrement plus grand que la couche d'éléments, mais lorsque nous progressons vers la couche de composants, nous voyons que les choses sont de loin beaucoup, beaucoup plus grandes. La couche de composants constitue la majeure partie de tout projet donné. La majorité de votre site Web sera basée sur des composants, ITCSS le soutient en créant une partie entière du projet pour toutes ces choses en direct. Ce que vous verrez est des noms cohérents, components.logo, components.masthead. C' est dans ces fichiers que nous trouvons la majorité de notre interface utilisateur. Enfin, nous nous dirigeons vers notre couche d'utilitaires et c'est à ce stade que nous importons n'importe quel type de fichiers de débogage ou n'importe quel utilitaire et sorte de classes d'aide. C' est à ce stade que nous pouvons apporter des fixateurs IE 7 spécifiques ou différents fixateurs pour différents navigateurs. couche Utilities est réservée pour CSS qui n'est pas tout à fait parfait. réservé à CSS qui est assez haute spécificité, souvent même contenant de l'importance. Nous examinerons cela plus en détail sous peu. En regardant ce fichier, nous devrions espérer voir que même un projet assez important peut être distillé en morceaux très gérables. Nous pouvons rapidement voir exactement ce qui vit où et pourquoi. Cela signifie que la recherche de CSS existant devient trivial et cela signifie que l'ajout de nouveau CSS devrait devenir assez simple et simple. En regardant les modèles qui ont été laissés par un développeur précédent, nous pouvons reprendre là où ils s'étaient arrêté et créer une base de code beaucoup plus cohérente. Comme vous pouvez le voir dans le fichier actuel que nous examinons, il a tous les ITCSS standard liés à l'heure actuelle. Mais certains projets peuvent nécessiter des couches différentes ou la suppression de certaines couches. L' ITCSS nous laisse tout à fait le soin de nous. C' était donc un coup d'œil rapide sur la façon dont le triangle peut se réunir dans un seul paquet SAS importé. Bien sûr, en fonction de votre projet, votre situation, de votre processus de construction, de votre pipeline de construction, les spécificités peuvent bien différer et la beauté de ITCSS est que c'est entièrement à vous de décider comment vous modifiez ce flux de travail. Ce que je veux vous montrer ensuite, cependant, est le fichier SCC résultant. Tous les diagrammes que nous avons dessinés précédemment étaient de la ligne 0-3000, c'est ce que nous avons utilisé, ils ont été représentés feuilles de style de compilation complètes. Regardons comment ça se passe. Maintenant, regardons comment tout cela se réunit une fois qu'il a été compilé dans une grande feuille de style. Immédiatement ici, nous aurons une table des matières familière, qui a été reportée à partir de notre point d'entrée principal, notre fichier .scss principal. Si nous passons par là, nous allons commencer à voir un SCSS naturel. Maintenant, rappelez-vous, les trois principes de base du triangle, faible spécificité vers une grande spécificité, inexplicitement vers explicite et large allant vers le bas jusqu'à la portée étroite. Donc, tout de suite, nous pouvons voir ici très faible spécificité. Vous avez un sélecteur d'étoiles, nous avons le sélecteur d'élément html, sont des sélecteurs de spécificité très faible qui lancent un filet très large. Le sélecteur d'étoiles capture littéralement tout dans le DOM. Donc, au fur et à mesure que nous avons progressé, et je vais le faire relativement rapidement, ce que vous devriez voir est le graphique de spécificité qui se forme sous vos yeux. Comme nous regardons à travers les sélecteurs d'éléments de faible spécificité, ensuite nous devrions commencer à voir certains sélecteurs de classe apparaître lorsque nous arrivons vers les objets. Ici, nous avons la mise en page 0, donc nous avons cette bosse de spécificité immédiate dans notre couche d'objets, la première couche dans laquelle nous sommes autorisés à voir les classes. Ce que vous remarquerez ici, c'est que ces classes sont effectuées avec un o-. Maintenant, il s'agit d'une convention de nommage facultative fournie avec ITCSS. progressant à partir d'ici, nous trouvons plus de classes, donc nous n'obtenons pas d'augmentation de la spécificité, mais nous obtenons un changement dans le but. Ici, nous avons à c - qui dénote nos classes de composants. Les composants sont les bits qui composent la majorité de l'interface utilisateur et ici nous voyons qu'il utilise une convention de nommage comme bamm. fur et à mesure que nous progressons au-delà des classes de composants, nous allons commencer à trouver des classes de spécificité très, très élevées. C' est là que nous arrivons à notre couche d'utilitaires. La couche Utilitaires est un cas particulier. Il est réservé à tous les types de CSS dont nous ne sommes pas particulièrement ravis. Sur les grands projets, il est garanti que cela va arriver, que vous devrez contribuer du CSS qui n'est pas tout à fait comme vous le souhaitez. Maintenant, ce n'est pas idéal. Bien sûr, ce n'est pas idéal, mais cela va probablement arriver, c'est arrivé sur tous les projets sur lesquels j'ai travaillé. Donc, ce qui est assez important est d'avoir un endroit dédié pour ces bits de CSS qui vivent notre couche d'utilitaires devient un catchall, un tiroir divers qui capture tout le CSS qui ne convient pas tout à fait ailleurs. laisser vers la fin signifie qu'il ne risque pas de donner le ton pour le reste du projet. Vous ne voulez pas appeler votre CSS hacky au début de votre feuille de style car cela signifierait que le reste de la feuille de style doit se battre autour d'elle. Nous dessinons tous ces trucs à la toute fin, sorte qu'il peut immédiatement remplacer tout ce qui est venu précédemment avec des frais généraux très minimes. fur et à mesure que nous progressons jusqu'à la fin de la feuille de style, nous constaterons que c'est là que les choses finissent. Nous terminons sur une spécificité très élevée avec des classes de cas à usage unique très, très ciblées. Ce sont des classes d'utilitaires qui sont conçues pour écraser tout ce qui est venu précédemment avec un minimum d'effort. Maintenant, je vous exhorte à aller absolument creuser autour ce dépôt parce que quand vous commencez à le séparer, vous trouverez bientôt toutes les choses dont nous avons discuté sont immédiatement en place, vous constaterez que les choses ont beaucoup plus de sens. Vous serez en mesure de naviguer très rapidement dans la base de code en fonction des choses conceptuelles que nous avons apprises plus tôt. Maintenant, bien sûr, ce n'était qu'une démonstration, pour l'amour de la démonstration. C' était une très petite démo, très autonome. Ce n'est pas nécessairement si réaliste d'une grande sorte de bête d'un projet. Donc, ce que vous trouverez, c'est que lorsque vous implémentez ITCSS dans le monde réel, les avantages deviendront beaucoup plus évidents, même dans cet exemple réduit, j'espère que nous apprenons qu'en suivant les trois principes fondamentaux de l'ITCSS, nous pouvons commencer à donner aux choses des endroits dédiés pour vivre et des endroits dédiés à trouver. Cela signifie que si un développeur qui parachute dans un projet peut facilement se localiser et naviguer facilement autour la base de code qu'il n'a jamais vu auparavant. 7. Réflexions finales: Donc, nous l'avons là, une introduction à l'architecture CSS Triangle inversé. Nous avons appris comment CSS, lorsqu'il est laissé à ses propres appareils, peut rapidement devenir indiscipliné et difficile à gérer. Mais nous avons également appris qu'avec beaucoup de diligence et une certaine formalité, nous pouvons facilement écrire ces choses et les aider à travailler à notre avantage. Surtout, ce que je veux vraiment que les gens retirent de cela, c'est le fait que ITCSS n'est pas un système complexe, il ne nécessite pas de changements radicaux dans le processus ou la forme. En plus de cela, c'est un toucher très léger. Ainsi, vous pouvez modifier ITCSS en fonction de votre pile technologique, compétences de votre équipe, la taille de votre projet, même du type de projet que vous travaillez. Sur le plan plus technique, je pense que ma clé à emporter pour vous serait, ai vraiment vraiment vraiment vraiment important de gérer des choses comme la spécificité très bien, parce que c'est généralement la façon technique dans laquelle les projets commencent à spirale le plus rapide. Alors, quoi ensuite ? La première chose que vous pourriez faire est de vous joindre à la discussion. Si vous avez des questions, des préoccupations, des exemples ou des téléchargements que vous aimeriez discuter ou sortir en plein air, absolument vous allez faire cela. Je garderai un œil là-dessus et répondrai à vos questions. Bien sûr, gardez un oeil sur les sections ressources, un tas de liens vers les différents documents de lecture et gardez un oeil sur cela. Il y a plein de trucs à regarder. Alors, c'était tout. Merci beaucoup de traîner. J' ai vraiment hâte de voir comment vous prenez ITCSS, moulez votre propre projet et votre propre travail, et je suppose que je vous verrai la prochaine fois.