Share
Au cas où vous ne l'auriez pas remarqué, le site d'analyse CSS cssstats.com a récemment fait l'objet d'une refonte. C'est un outil superbement conçu qui vous donne beaucoup d'informations objectives sur votre code, mais comment utiliser au mieux les statistiques CSS? Que devriez-vous viser? Que veulent-ils dire et comment pouvez-vous les utiliser au quotidien??
Aujourd'hui, nous allons parler des meilleures pratiques CSS, de leur spécificité et de leur facilité de maintenance. Vous apprendrez également à interpréter correctement les statistiques CSS et à les utiliser au mieux. Plongeons dedans!
Rendez-vous sur cssstats.com, entrez l'URL de votre site Web, sa feuille de style ou collez le code CSS brut directement dans la zone de texte en bas, puis cliquez sur Aller.
Une fois analysé, vous recevrez une tonne de statistiques sur le CSS; à partir du nombre de règles utilisées, leur taille moyenne, la ventilation de chaque type de déclaration, les couleurs de police et d'arrière-plan, les familles et tailles de police et les graphes de spécificité.
C’est ce que vous donne les statistiques CSS. Voyons maintenant ce que nous pouvons faire avec toutes les données..
En tant que développeurs front-end, nous sommes constamment préoccupés par les performances et l'expérience utilisateur. Nous sommes également responsables de la création de logiciels, mais le mot «logiciel» est étranger à de nombreux développeurs front-end issus de la conception. Il est souvent facile d'ignorer les meilleures pratiques lorsque nous codons notre code CSS..
Cependant, la vérité est que le développement frontal, comme tout développement de logiciel, nécessite de se concentrer sur les meilleures pratiques. Les règles relatives aux meilleures pratiques sont abondamment discutées sur le Web, mais dans l’intérêt de cet article, nous allons nous concentrer sur ce qui est sans doute la pratique la plus importante en matière de CSS: la maintenabilité..
La maintenabilité des CSS sur de nombreuses facettes.
Nous ne nous intéresserons pas à chacun de ces éléments individuellement, mais lorsque nous parlons de maintenabilité, chacune de ces considérations affecte la maintenabilité globale de votre base de code..
La réponse honnête? Rien, nécessairement. Vous n'apprenez rien sur la maintenabilité en regardant simplement les statistiques CSS. Vous devez également comprendre le contexte de ce CSS particulier, ainsi que le contexte du développement actif..
La première façon d’analyser vos statistiques CSS consiste à rechercher des signes de gonflement CSS..
Par gonfler nous voulons dire CSS non utilisé, redondant ou autrement inutile.
Prenons, par exemple, une application d'une page comportant cinq modules de contenu différents. Quels types de statistiques CSS attendriez-vous d'une seule page? Une application typique d'une page peut avoir une fraction du nombre de règles CSS et peut-être la moitié du nombre de déclarations de couleur sous la forme d'un grand site de publication d'actualités ou d'une application SAAS à facettes multiples.
Si vous voyez un nombre énorme de sélecteurs (par exemple, si votre site simple page comprend autant de CSS qu'un framework Web tel que Bootstrap, qui compte un peu moins de 2 400 sélecteurs), il est probable que vous vous êtes trompé quelque part. . Si vous chargez 30 tailles de police et que votre conception en appelle 10, il est probable que vous ayez des styles inutilisés, gonflés ou éventuellement incohérents..
Une exception possible à cette règle, en ce qui concerne la maintenabilité, est si vous êtes réellement utiliser Bootstrap ou un autre framework populaire bien documenté; parce que la documentation sur ces projets est relativement approfondie et que l'utilisation a saturé le Web, les développeurs front-end maintenir Bootstrap, tant que la source principale conserve les implémentations principales de Bootstrap. Toutefois, si vous incluez le cadre Bootstrap uniquement à la grille ou à quelques éléments de l'interface utilisateur, vous devez créer une version personnalisée qui n'inclut pas le CSS supplémentaire que vous ne prévoyez jamais d'utiliser..
Il est possible que votre application fasse quelque chose qui nécessite un grand nombre de sélecteurs, de couleurs ou de tailles de police. Par exemple, si vous exploitez une boutique en ligne qui utilise des couleurs de produit, il est possible qu'un grand nombre de couleurs apparaissent dans votre code CSS et constituent un cas tout à fait légitime. Un autre exemple est si vous exécutez un site qui permet aux utilisateurs de sélectionner dans une liste de tailles de police et des polices pour le contenu qu'ils créent. Dans ces exemples, il est logique de voir de grands nombres dans ces catégories particulières.
Medium.com utilise une taille de police de 301px quelque part… Toutefois, si vous créez quelque chose comme un blog avec un jeu de couleurs limité, vos statistiques CSS doivent refléter le nombre de sélections de couleurs et de déclarations de polices..
Définissez-vous la même taille de police vingt fois dans votre CSS? Très souvent, cela peut être évité et résulte généralement d'un manque de planification. Si vous déterminez la taille de vos polices avant d'écrire un autre fichier CSS, vous pourrez plus facilement appliquer ces tailles au reste du système..
La même chose est vraie pour tout style répété; si vous vous retrouvez à écrire la même chose plusieurs fois, cet ensemble de styles mérite peut-être sa propre classe de présentation ou sémantique ou une autre définition modulaire?
Ne va pas trop loin ici; redéfinir quelques tailles de police ou couleurs d’arrière-plan n’est pas une mince affaire. Cependant, redéfinir plusieurs fois un certain nombre de styles sur des modules très similaires peut signifier que vous devriez étendre une classe de base. Par exemple, si vous avez une classe de boutons:
.btn font-size: 1.2em; poids de la police: 400; espacement des lettres: 0,06em; couleur: #fff; couleur de fond: # 4a4a4a; rembourrage: 6px 8px;
Supposons que vous souhaitiez une version bleue de ce même bouton. Comment devriez-vous vous y prendre pour définir cela? Si vous redéfinissez le même btn classe, ça ressemblerait à quelque chose comme ça:
.btn-blue taille de la police: 1.2em; poids de la police: 400; espacement des lettres: 0,06em; couleur: #fff; couleur de fond: # 0C508D; rembourrage: 6px 8px;
Bien sûr, cela pose de nombreux problèmes. Premièrement, cela viole le principe DRY (ne vous répétez pas). Mais pourquoi est-ce important? Maintenabilité. Disons, par exemple, que la conception change et appelle une police plus petite sur les boutons. Vous devez ensuite aller dans le .btnet la .bleu btn classe pour changer la taille de la police. La complication est encore plus grande lorsque vous avez besoin de variantes des boutons gris et gris normaux, comme une version avec contour bleu. Toutes vos modifications sur un bouton doivent être effectuées sur plusieurs boutons..
C'est incroyablement inefficace. Vous devriez plutôt tirer parti du fait que les classes sont modulaires et vous permettent de définir des styles de boutons qui étendent votre base. .btn classe.
.btn font-size: 1.2em; poids de la police: 400; espacement des lettres: 0,06em; couleur: #fff; couleur de fond: # 4a4a4a; rembourrage: 6px 8px; .btn.btn-blue background-color: # 0C508D;
Aha! Et nous avons maintenant une solution beaucoup plus facile à gérer, qui supprime également un nombre important de lignes de CSS et suit le principe DRY.
La spécificité est l’un des recoins sombres les plus difficiles à comprendre de CSS qui surprend souvent même les développeurs les plus expérimentés. Dans les statistiques CSS, vous pouvez voir un tableau de spécificité indiquant la spécificité des sélecteurs dans votre CSS, ainsi que l'emplacement de ces sélecteurs..
Spécificité CSS du site Web de la BBCCe graphique montre la spécificité des sélecteurs rencontrés dans le CSS de bbc.co.uk. Imaginez que la gauche du graphique se trouve en haut de la feuille de style, puis qu’elle se déplace le long de la axe x comme il se lit la feuille de style. Plus la règle est précise, plus la ligne bleu foncé est haute axe des y.
Nous fournirons trois «règles empiriques» pour commencer, puis nous expliquerons les règles..
Nous parlerons de chacune de ces choses de manière plus approfondie, mais parlons d'abord un peu du fonctionnement de la spécificité..
Les sélecteurs CSS se voient attribuer un score de spécificité pour informer le moteur de rendu du navigateur des règles qui s'appliquent à quels éléments. La raison pour laquelle cela est nécessaire est également la raison pour laquelle CSS est si puissant: les styles peuvent être hérités et cascadés en CSS. Cela signifie que vous pouvez appliquer plusieurs ensembles de styles à un élément donné. Le moteur de rendu doit consolider toutes ces règles et présenter quelque chose, mais que se passe-t-il lorsque deux valeurs différentes sont définies pour la même déclaration de style? Par exemple:
a color: #fff; a.button color: # 000;
Lorsque le moteur CSS rencontre un tag avec une classe de bouton, il doit déterminer si le Couleur attribut devrait être #fff, # 000, ou le navigateur par défaut. La spécificité CSS est le jeu de règles utilisé par le navigateur pour prendre cette décision..
Alors, comment fonctionne la spécificité? Utilisez ce système de notation comme guide, tiré directement de CSS Tricks:
Accentsconagua
!important les dépasse tous* les sélecteurs obtiennent un score de spécificité de tous les 0.Notez que dans ce système de notation, lorsque quelque chose dépasse 10, il ne va pas dans la colonne suivante. Ainsi, par exemple, si vous avez un sélecteur de 11 éléments, il ne débordera pas pour être une spécificité de 0, 0,1,1. Il serait plutôt 0,0,0,11.
Voici quelques sélecteurs et leurs résultats.
nav li a / * 0,0,0,3 * / .nav-item / * 0,0,1,0 * / nav .nav-item / * 0,0,1,1 * / #logo / * 0,1,0,0 * /
a couleur de fond: bleu! important; / * Dans l'exemple précédent, nous avons utilisé des styles en ligne pour définir la couleur d'arrière-plan sur rouge. Cependant, si nous appliquions ce style avec le qualificateur! Important, il remplacerait le style en ligne. * /
D'accord - maintenant que nous avons une introduction de base pour la spécificité CSS, comment cela devrait-il influencer notre code? Revenons à nos trois règles de base pour la spécificité CSS.
Cette règle indique essentiellement que les sélecteurs généraux doivent figurer au début de votre CSS, et que des sélecteurs plus spécifiques doivent apparaître plus tard dans votre CSS. Les raisons de cette règle sont nombreuses.
Premièrement, le fait de placer des règles générales au début de votre application ouvre généralement la voie dans votre code pour la création de modules de base. En conjonction avec # 2, avoir le moins de styles spécifiques au début vous assure que vous écrivez avec le moins de spécificité possible. Plus tard, à mesure que votre code évolue, il peut être nécessaire d’ajouter des styles plus spécifiques pour remplacer ou étendre les styles précédents..
Les styles sur le site Web d'Apple sont très spécifiques au début de la feuille de style
La spécificité du framework Pure CSS augmente généralement vers la fin de la feuille de styleCela nous amène à notre deuxième point: que se passe-t-il lorsque le moteur de rendu CSS rencontre deux sélecteurs ayant le même score? Il lui reste à choisir, il va donc opter pour la dernière des deux règles. En vous trompant de précision au début de votre fichier, vous vous assurez que vos substitutions de spécificité sont plus spécifiques au fur et à mesure que vous avancez dans le fichier. Cela signifie qu’une classe ultérieure dans le fichier doit être considérée comme capable de remplacer des classes individuelles plus tôt dans le fichier..
Cette pratique garantira que les développements ultérieurs sur le même projet peuvent comprendre rapidement le système en cascade..
Si vous avez été développeur front-end pendant longtemps, vous avez probablement vécu la «guerre de la spécificité CSS». Vous écrivez un sélecteur et quelques règles, puis actualisez le navigateur uniquement pour constater que les modifications n'ont pas été appliquées. Les projets précédents ou les conversations sur la spécificité vous expliquent que c'est parce que votre sélecteur n'est pas assez spécifique. Au lieu d'essayer de remonter le problème au sélecteur trop spécifique, vous décidez de créer le nouveau. plus spécifique. Vous ajoutez un ID ou deux, et si cela ne fait pas l'affaire, vous jetez simplement !important à cela. Et, le tour est joué - vos styles apparaissent.
Cette approche fonctionne techniquement. mais malheureusement, chaque fois que vous souhaitez étendre ce style, vous devez continuer à augmenter la complexité, et avant de vous en rendre compte, vos sélecteurs sont extrêmement spécifique, et vous devez répéter le code plutôt que de simplement réutiliser les classes. De plus, il est presque impossible de déterminer exactement le niveau de spécificité que devraient avoir les nouveaux styles sans ajouter de plus en plus d'identifiants et !important déclarations.
Garder vos sélecteurs moins spécifiques est un moyen beaucoup plus sain et plus facile à gérer pour gérer vos CSS.
Cette règle est principalement en place pour éviter les règles étrangement placées. Par exemple, si vous définissez certaines classes pour la présentation de texte et que vous avez soudainement une règle qui imbrique six classes et un ID, cette règle particulière doit être placée en contexte avec des sélecteurs plus spécifiques auxquels elle est liée..
Les statistiques CSS peuvent vous donner un aperçu de la façon dont votre CSS est écrit, mais cela n’est utile que si vous avez une idée de ce à quoi ces statistiques devraient ressembler avant d’essayer de les analyser. Cela signifie avoir une compréhension contextuelle profonde de la façon dont votre CSS est écrit et pourquoi. Si votre CSS est maintenable et approprié pour le site sur lequel il est utilisé, les statistiques de ce CSS ne sont pas une raison suffisante pour refactoriser votre code.
Au lieu de suivre à l'aveuglette les règles de numérotation, en tant que développeur front-end responsable, vous devez vous attacher à rendre votre code maintenable et à réduire le fardeau. Les statistiques sur votre code peuvent vous aider à identifier les problèmes, mais elles ne peuvent aller aussi loin.
