Un guide de débogage CSS —

Le débogage en CSS signifie déterminer quel pourrait être le problème lorsque vous obtenez des résultats de mise en page inattendus. Nous examinerons quelques catégories dans lesquelles les bogues entrent souvent, voir comment nous pouvons évaluer la situation et explorer des techniques qui aident à prévenir ces bogues.

Nous sommes tous passés par là, à la fin du CSS pour une mise en page et — qu'est-ce que c'est ? Ah ! Une barre de défilement supplémentaire ! Ou peut-être qu'un élément est une couleur inattendue. Et sur certains navigateurs, cette nouvelle fonctionnalité ne semble tout simplement pas fonctionner.

Le débogage – quelle que soit la langue – n'est jamais une tâche préférée. CSS, comme d'autres langages, devient plus facile à déboguer lorsque vous prenez le temps d'en apprendre un peu plus sur ses bizarreries. Il est également utile de se familiariser avec les outils pour vous aider à la fois à déboguer et à éviter de créer des bogues. problème. D'après mon expérience, les problèmes de mise en page CSS relèvent souvent de l'une des catégories suivantes :

1. Débordement de contenu de son parent entraînant des barres de défilement supplémentaires ou inattendues et du contenu poussé hors de la zone d'affichage normale.
2. Héritage incohérences du navigateur conduisant à des résultats mitigés entre les navigateurs et les appareils.
3. Héritage inattendu de la cascade où plusieurs styles se remplacent, ce qui peut entraîner des problèmes d'alignement et d'espacement, entre autres.
4. Échecs de résilience CSS. des modifications du DOM y compris lorsque les éléments enfants ont gagné des div d'encapsulation ou que des éléments supplémentaires sont ajoutés de manière inattendue. pour identifier les styles incriminés. Bien sûr, nous discuterons également des solutions possibles à ces bogues.

   Conseils de débogage généraux

   Lorsque quelque chose ne va pas dans votre CSS, vous pouvez commencer par utiliser les outils de développement intégrés de votre navigateur préféré pour :

   • désactiver les règles une par une
   • désactiver toutes les règles et les ramener une à la fois
   • supprimer ou déplacer des éléments

   En raison de la nature globale de CSS, le style problématique d'un élément peut être situé dans son parent, ses grands-parents ou même plus haut dans l'arbre. DevTools affichera les règles les plus applicables à l'élément en fonction de la spécificité en haut du volet, puis fournira une trace de pile de la cascade et des styles hérités.

   

   Vous pouvez également essayer d'isoler le problème de mise en page spécifique en plaçant uniquement cette partie dans un fichier local ou en utilisant un éditeur en ligne comme CodePen ou CodeSandbox. Sachez que l'utilisation de ces éditeurs peut insérer des opinions supplémentaires que votre environnement local n'a pas. Par exemple, CodePen utilise par défaut la réinitialisation Normaliser, ce qui peut introduire de nouveaux problèmes si vous ne l'utilisez pas déjà. Désactivez tous les paramètres qui ne fonctionnent pas pour votre projet. Ensuite, vous pouvez utiliser DevTools pour copier dans le code HTML approprié.

   Après cela, une autre fonctionnalité pratique consiste à ouvrir le menu contextuel ("clic droit" ou équivalent) pour votre élément, puis sélectionnez "Copier > Copier les styles" dans le menu contextuel. menu. Répétez l'opération pour chaque élément imbriqué si nécessaire.

   

   Si le problème n'existe plus après l'avoir isolé, il est probable qu'un élément ancêtre soit à l'origine des difficultés. Vous pouvez choisir d'isoler en commençant par le haut de l'arborescence DOM, ou vous devrez probablement inspecter l'héritage de plus près. Nous parlerons un peu plus de l'héritage plus tard.

   Si vous pouvez résoudre le problème dans votre composant isolé, vous pouvez réintégrer les styles mis à jour dans la feuille de style de votre projet principal.

   

   Chrome, Edge, Firefox et Safari ont également un moyen de suivre les modifications que vous avez apportées et de les enregistrer pour vous permettre de copier plus facilement les mises à jour.

   • Chrome/Edge
     Utilisez le menu plus « kebab » pour sélectionner « Plus d'outils > Modifications » pour ouvrir ce panneau. De plus, vous pouvez conserver vos modifications en utilisant la fonctionnalité remplacements locaux.
   • Firefox
     Le panneau "Modifications" devrait déjà être disponible par défaut et à côté de l'onglet "Calculé".
   • Safari
     Propose également le panneau « Modifications » par défaut, situé dans la même barre d'onglets que les « Styles ».

   Lecture recommandée : « Examiner et modifier le CSS », Firefox Developer Tools, MDN Web Docs

   Plus d'idées, de conseils et d'outils seront discutés ensuite.

   Plus après le saut ! Continuez à lire ci-dessous ↓

   Debugging Overflow

   Le débordement est généralement l'un des problèmes les plus apparents et peut être assez frustrant. Il n'est pas toujours évident d'un coup d'œil quel élément provoque le débordement, et il peut être fastidieux d'essayer de parcourir les éléments à l'aide des inspecteurs d'outils de développement.

   « CSS est conçu pour ne pas perdre de contenu, pour ne pas provoquer préjudice. Afin de ne pas nuire, nous montrons ce qui déborde par défaut. « CSS est génial » est, en fait, un comportement correct et intentionnel si la boîte de base a été délibérément définie plus petite que la taille nécessaire pour accueillir ce texte. (Si vous êtes intéressé, le créateur original, Steven Frank, s'est arrêté par CSS Tricks pour expliquer l'origine ).

   

   Une méthode éprouvée pour commencer à déterminer quel élément est responsable du débordement consiste à ajouter le CSS suivant :

   * {
     contour : 1px rouge uni ;
   }
   

   Pourquoi contour au lieu de bordure ? Parce que cela n'ajoutera pas à la taille DOM calculée de l'élément. L'ajout de bordures modifiera l'apparence des éléments s'ils utilisent déjà une bordure et peut faussement provoquer des problèmes de débordement supplémentaires. page. »/>

   L'intention d'utiliser outline est de révéler les limites des éléments et de visualiser comment les éléments sont imbriqués. Par exemple, si le débordement provoque des barres de défilement inattendues, un contour peut aider à indiquer quel élément pousse hors de la fenêtre d'affichage.

   En plus de cette méthode manuelle, Firefox révèle les éléments de défilement et spécifie quels éléments ont des enfants provoquant le débordement, comme vu dans cette capture d'écran.

   

   Causes courantes de débordement

   Généralement, lorsque nous sommes préoccupés par les problèmes de débordement, cela provient d'une inadéquation des tolérances de largeur entre un élément parent et ses enfants.

   L'une des premières choses à vérifier est si un élément a définissez une largeur absolue sans méthode réactive pour lui permettre de redimensionner complètement vers le bas. Par exemple, une case 600px déclenchera un débordement sur les viewports plus étroits que 600px. Au lieu de cela, vous pourrez peut-être ajuster pour ajouter une max-width : 100% afin que l'élément soit également redimensionné de manière réactive :

   .wide-element {
     largeur : 600px ;
     largeur maximale : 100 % ;
   }
   

   Un exemple de cas où cela ne serait pas une solution complète est lorsque l'élément déclenchant le débordement a également des marges qui augmentent sa taille calculée dans son parent. Dans l'exemple suivant, le paragraphe est toujours forcé en dehors de l'élément main en raison de sa marge horizontale.

   

   Heureusement, nous pouvons tenir compte de cette marge en utilisant la fonction mathématique CSS calc pour soustraire la surface totale utilisée par les marges horizontales :

   p:first-of-type {
     largeur : 800px ;
     largeur max : calc(100% - 6rem);
     marge : 3rem ;
   }
   

   Cela dit, ce n'est pas souvent que nous devrions fournir des largeurs absolues pour les éléments. Le plus souvent, il serait préférable de ne définir que max-width si vous devez contrôler la taille d'un élément. Encore une fois, cela réduit les bogues liés au dimensionnement réactif. En fait, nous pouvons complètement résoudre les problèmes de notre exemple en supprimant à la fois les valeurs width et max-widthce qui permet au comportement par défaut du paragraphe de le laisser s'ajuster de manière appropriée dans l'espace disponible du parent main.

   Cependant, il existe des situations où les solutions que nous avons examinées ont du sens, telles que l'application de max-width: 100% pour créer des images réactives. Et pour certaines méthodes de mise en page basées sur flexbox, vous verrez également width ou flex-basis utilisé avec calc pour tenir compte de la marge.[19659003]Un autre déclencheur courant de débordement concerne l'une des erreurs reconnues dans la conception de CSS par le groupe de travail CSS. Numéro 6, en fait, qui est que box-sizing aurait dû être défini par défaut sur border-box au lieu de content-box.

   Tous les navigateurs sont actuellement livrés avec la décision héritée de définir le modèle de boîte d'élément pour utiliser content-boxce qui signifie que la bordure et le remplissage d'un élément sont ajoutés au calcul de la taille de l'élément. Ainsi, si vous définissez des dimensions absolues pour la largeur et/ou la hauteur, vous devez tenir compte de l'espace supplémentaire pour toute bordure et remplissage ajoutés.

   Pour simplifier ce comportement, une meilleure pratique consiste à vous assurer que vos styles incluent la réinitialisation de tous les éléments sur utilisez border-box. Cela réduit le risque de débordement dans de nombreux cas et rend la mise en page CSS plus prévisible en éliminant les complications liées à l'inclusion de bordures et de remplissage dans les dimensions finales de l'élément.

   *,
   *::avant,
   *::après {
     dimensionnement de la boîte : border-box ;
   }
   

   D'autres causes de débordement s'intègrent un peu mieux dans les catégories de bugs que nous examinerons ensuite. il y a encore des choix hérités qui peuvent interférer. Chaque navigateur est livré avec une feuille de style par défaut appelée user-agent (UA) styles.

   Voici un exemple de la façon dont ces styles apparaissent dans les navigateurs principaux :

   

   Ceux-ci mettent en évidence l'une de ces valeurs par défaut qui peuvent être un autre déclencheur courant de débordement. L'élément body a une marge attachée dans chaque navigateur, avec les premiers comme commenté :

   body {
     /* Chrome et Firefox */
     marge : 8px ;
     /* Safari/kit web */
     marge supérieure : 8px ;
   }
   

   Vous connaissez peut-être le concept de réinitialisation CSS. Ceux-ci ont évolué au fil des ans, car la prise en charge de CSS et du navigateur s'est améliorée, mais la réinitialisation du body à la marge : 0 est généralement une fonctionnalité.

   Si vous utilisez CodePen, la valeur par défaut reset est Normalize.cssécrit par Nicolas Gallagher et initialement publié en 2012. Il peut être trouvé dans de nombreux projets et est un reset assez opiniâtre. Cependant, il convient de noter qu'il n'a pas été mis à jour depuis novembre 2018.

   Note : Une autre note opportune ici est qu'Internet Explorer atteindra officiellement la fin de vie le 15 juin, 2022 ). Cela signifie que de nombreuses fonctionnalités sont nécessaires non seulement dans les réinitialisations, mais dans nos feuilles de style, en général, ne seront plus nécessaires !

   Le CSS s'est amélioré rapidement au cours des deux dernières années, et bien sûr, les navigateurs sont continuellement modernisateur. Une réinitialisation alternative qui convient mieux aux projets plus modernes est Modern CSS Reset d'Andy Bell . Cette réinitialisation est suffisante pour lisser la poignée de choses communes à la plupart des projets qui sont encore incohérentes entre les navigateurs, sans être trop opiniâtre. Il prend également en compte quelques fonctionnalités d'accessibilité de base. Andy explique chaque règle de la réinitialisation, et j'ai trouvé que c'était un point de départ solide.

   Regardons quelques incohérences du navigateur moderne qui peuvent provoquer des bogues de mise en page.

   Débordement des unités de visualisation et des barres de défilement

   Sans supprimer la margin sur le bodynotre exemple simple de la section de débordement déclenche un débordement. C'est parce que nous avons utilisé 100vw comme l'une des valeurs possibles pour le width de l'élément main. Comme il ne soustrait pas la margeil subit un débordement car 100vw est 16px plus large que l'espace disponible entre les marges du corps.

   Selon le navigateur et le système d'exploitation, vous pouvez également rencontrer des largeurs de barre de défilement du navigateur qui perturbent également le calcul 100vw. Actuellement, le correctif consiste à mettre à jour vers 100% si vous le pouvez.
   Bientôt, nous aurons également la propriété scrollbar-gutter pour nous aider à prendre en compte la largeur des barres de défilement. Cette propriété est en cours d'extension dans CSS Overflow Module Level 4 et a été prise en charge dans les navigateurs Chromium à partir de la version 94. Bramus a une excellente ventilation de scrollbar-gutter de la façon dont cela va travail et ce qu'il aidera à résoudre. Le résumé de la solution est de s'assurer de laisser de la place pour les barres de défilement tout en obtenant une apparence uniforme des deux côtés du contenu en ajoutant : overflow: auto; scrollbar-gutter: stable both-edges;.

   Remarque :Si vous n'êtes pas sûr que votre contenu nécessite des barres de défilement mais sachez qu'il peut en avoir besoin parfois, assurez-vous d'utiliser la valeur auto pour le débordement. Cela indique au navigateur de ne les ajouter que lorsque l'élément en a besoin pour accueillir le contenu. Cela dit, les utilisateurs peuvent personnaliser leurs préférences pour toujours afficher les barres de défilement, c'est pourquoi la propriété scrollbar-gutter sera très précieuse !

   Il peut également être problématique de définir min- hauteur : 100vh sur le corps sans enlever la marge au préalable. Il y a d'autres problèmes avec 100vh spécifiquement, et ceux-ci ont à voir avec la façon dont différents appareils et combinaisons de navigateurs ont implémenté le calcul pour 100vh.

   Tandis que 100vh semble fonctionner sur la plupart des contextes de bureau, vous avez peut-être ressenti la frustration d'avoir ce qui semble être un comportement inattendu, en particulier lorsqu'il est testé sur iOS dans les navigateurs WebKit. Dans une mise en page fixe définie sur 100vhla partie inférieure du contenu du site Web est bloquée derrière le chrome du navigateur, ce qui la rend inaccessible lorsque le défilement est empêché. Par exemple, dans un menu mobile à hauteur fixe ou une application ou un jeu d'une seule page essayant de ne pas remplir plus que la hauteur de la fenêtre d'affichage disponible.

   Matt Smith est allé chercher une solution et a découvert dans certains scénarios le ]Le problème 100vh peut être résolu en utilisant la combinaison suivante :

   html {
     hauteur : -webkit-fill-available ;
   }
   
   corps {
     hauteur minimale : 100 vh ;
     /* Correction d'un bug de la fenêtre d'affichage mobile */
     min-height : -webkit-fill-available ;
   }
   

   Cette solution est imparfaite, et je suggère de tester sur un appareil réel pour s'assurer qu'il fonctionne pour votre mise en page.

   Jen Simmons a également partagé une technique (horodatage : 13 m) qui est disponible dans Safari 15 pour ajuster ce comportement à l'aide de variables d'environnement CSS. Le safe-area-inset-bottom sera 0 lorsqu'il n'est pas applicable et s'ajustera dynamiquement lorsqu'il s'appliquera. Cette variable d'environnement peut être utilisée pour le remplissage, la marge et dans calc comme indiqué :

   body {
     min-height: calc(100vh - env(safe-area-inset-bottom));
   }
   

   Le groupe de travail CSS a une solution améliorée dans le projet pour résoudre cette catégorie de problèmes, qui sera un ensemble de nouvelles unités pour " Grandes, petites et tailles de fenêtres dynamiques ". Ceux-ci sont destinés à mieux correspondre au comportement dynamique du chrome du navigateur changeant, car c'est la cause des problèmes de WebKit.

   Voici un résumé du brouillon actuel (notez que ceux-ci peuvent encore avoir quelques changements avant qu'ils ne soient stables dans les navigateurs) :

   • Petites unités de pourcentage de la fenêtre (svh, svb, svw, svi)
     Équivalent à l'espace restant de la fenêtre lorsque tous les éléments dynamiques de l'interface utilisateur sont développés (par exemple, la barre d'URL et le clavier virtuel), et ne seront pas modifier sa valeur même lorsque le chrome du navigateur change.
   • Grandes unités de pourcentage de la fenêtre d'affichage (lvh, lvb, lvw, lvi)
     La taille opposée à petite, calculée pour supposer que tous les éléments dynamiques de l'interface utilisateur sont rétractés.
   • Dynamique viewport-percentage units (dvh, dvb, dvw, dvi)
     La valeur instable de l'espace de la fenêtre visible qui change avec les changements dynamiques de chrome du navigateur.

   Propriétés des éléments de typographie

   Les styles UA incluent également des styles par défaut pour les éléments de typographie tels que la tête ings, des paragraphes et des listes. En règle générale, les réinitialisations ou les frameworks CSS auront déjà résolu ces problèmes. Et, bien que vous ne puissiez pas considérer les différences dans ces propriétés comme des « bogues », il est utile de comprendre qu'il ne s'agit pas des mêmes paramètres par défaut entre les navigateurs, car ces styles sont parmi les plus percutants.

   La note principale ici est que si vous remarquez une incohérence, vous pouvez sélectionner votre valeur préférée (comme une font-size particulière pour un h1) et l'ajouter à votre feuille de style.

   Différences dans Prise en charge des fonctionnalités du navigateur

   Les différences de navigateur dans la prise en charge des fonctionnalités sont la catégorie la plus frustrante, allant des navigateurs modernes au début de CSS. Tout simplement, tous les navigateurs ne prennent pas en charge toutes les propriétés CSS de manière égale. Ainsi, les problèmes que nous avons dus à la prise en charge des fonctionnalités diminuent, mais en même temps, nous sommes dans une phase d'attente en attendant que les nouvelles choses soient disponibles pour le grand public.

   Heureusement, nous avons plusieurs outils disponibles pour aider à la recherche. prise en charge des fonctionnalités pendant le développement et pour aider à résoudre les incohérences.

   Celui que vous connaissez peut-être déjà est caniusequi répertorie les tables de prise en charge des fonctionnalités CSS et JavaScript. La mise en garde à prendre en compte ici est que les données d'utilisation du navigateur sont basées sur Statcounterun échantillon de 2 millions de sites Web. Par conséquent, les pourcentages peuvent ne pas correspondre à votre public et ne devraient être qu'un point de données pour essayer de déterminer s'il est « sûr » d'utiliser une fonctionnalité particulière pour votre projet.

   Un autre outil utile est l'extension VSCode webhintqui alimente également une partie du panneau Problèmes dans Edge. Webhint vous alerte sur les fonctionnalités qui peuvent avoir une prise en charge inférieure du navigateur pour vous aider à être conscient pendant le développement. Vous pouvez configurer les navigateurs pris en compte en incluant une browserslist dans votre package.

   Connaître la prise en charge des fonctionnalités pendant le développement vous aide à créer une solution éclairée. Mais parfois, il ne s'agit pas de savoir si une fonctionnalité est strictement prise en charge, mais si la propriété a subi ou non des modifications de syntaxe. Par exemple, les propriétés sont parfois publiées avec des « préfixes de fournisseur ». Vous les avez probablement déjà vues — celles qui commencent par -webkit ou -moz.

   Habituellement, la version stable de la propriété ne continue pas à avoir un préfixe, mais c'est préférable d'inclure la version préfixée pour la prise en charge la plus large. Heureusement, vous pouvez automatiser cette étape au lieu de le faire manuellement avec le populaire package autoprefixer. De plus, il est possible de l'inclure dans de nombreux processus de construction, tels que postCSS (la méthode que j'utilise). Comme Webhint, il examine votre liste de navigateurs pour déterminer le niveau de prise en charge pour fournir des propriétés préfixées.

   Au-delà de ces outils, les outils de développement de chaque navigateur ont une méthode pour indiquer quand ce navigateur ne prend pas en charge une propriété . Chromium, Safari et Firefox affichent un triangle d'avertissement jaune à côté d'autres styles et une propriété déclenchée par le survol pour indiquer une propriété non prise en charge. , Safari ne prenant pas non plus en charge le rapport hauteur/largeur. ( Grand aperçu)
   

   Examiner comment gérer le manque de prise en charge d'une fonctionnalité dépasse un peu le cadre de cet article. Et, fournir des solutions de secours si nécessaire ou mettre en place des solutions en tant qu'améliorations progressives sera unique. C'est pourquoi il est si important de vous mettre en place avec des outils pour vous aider à vérifier le support pendant le développement. Ensuite, vous pouvez créer une solution qui correspond au niveau de support dont vous avez besoin au lieu d'avoir une solution complète que vous devez ensuite déboguer et définir une solution de secours pour une fois que vous obtenez des rapports de bogue.

   Héritage de disposition en cascade inattendu

   D'accord, vous avez donc l'impression d'utiliser des fonctionnalités CSS bien prises en charge. Et vous venez d'ajouter une nouvelle section à votre site, et vous vous sentez assez confiant sur le CSS. Mais quand vous allez le regarder dans le navigateur, les choses semblent incorrectes.

   En particulier lorsque vous utilisez un framework ou un système de conception et que vous écrivez également du CSS personnalisé, nous pouvons rencontrer des bugs liés à la cascade et à l'héritage. Quelque chose qui fonctionne de manière isolée peut ne pas fonctionner lorsqu'il est placé dans une disposition d'écran.

   Heureusement, tous les outils de développement de navigateur permettent de tracer la cascade. En examinant le panneau Styles, nous pouvons voir quelles règles remplacent nos styles. Ou, nous pouvons localiser un parent qui ajoute une méthode de mise en page que nous n'attendions pas pour notre composant enfant.

   Cet exemple simple montre que la règle pour main * est « gagnant » la cascade pour l'application couleur au paragraphe. Les outils de développement manipulent l'ordre dans le panneau Styles pour afficher les styles les plus applicables en haut. Ensuite, nous pouvons voir que la propriété de couleur pour seulement p est barrée comme un indicateur supplémentaire que cette définition de règle n'est pas appliquée.

   Grand aperçu

   )
   

   Revenons rapidement aux bases CSS de la cascade. Pour cet exemple, certains d'entre vous ont peut-être réalisé que main * a une spécificité égale à p. Mais l'autre partie très critique de la cascade est l'ordre des règles, et voici l'ordre de la feuille de style pour l'exemple :

   body {
     couleur : #222 ;
   }
   
   p {
     couleur : 444 ;
   }
   
   principale * {
     couleur : hsl (260, 85 %, 25 %) ;
   }
   

   Si nous voulons nous assurer que la règle pour seulement p « gagne », alors nous devons soit nous assurer qu'elle suit la règle principalesoit augmenter sa spécificité.

   Cette fonctionnalité de base de CSS est extrêmement puissante mais peut être perçue comme un « bogue » si vous n'êtes pas aussi familier avec son fonctionnement. Et cela peut certainement être frustrant si vous êtes chargé de déployer une nouvelle fonctionnalité sur une base de code héritée ou si vous devez utiliser un cadre où il est plus difficile de contourner la spécificité héritée.

   La résolution des problèmes dus à la cascade n'a souvent pas réponse facile. Cela vaut la peine de prendre du recul par rapport au problème immédiat et d'examiner les couches de styles qui se réunissent pour identifier le meilleur endroit pour effectuer un changement. Reconnaissez qu'un !important pourrait vous causer d'autres problèmes liés à la spécificité sur toute la ligne, alors essayez d'abord de réorganiser les propriétés si possible. Ou, vous pouvez passer à la configuration de « composants », qui fournissent une couche de portée pour les styles et encouragent à être plus intentionnel en matière d'héritage.

   En parlant de couches – accélérer le processus de spécification est une autre nouvelle fonctionnalité conçue spécifiquement. pour aider à orchestrer la cascade et à atténuer les affrontements. À l'heure actuelle, la spécification Cascade Layers (@layer) a obtenu une prise en charge expérimentale dans tous les principaux navigateurs. Pour plus d'informations sur cette fonctionnalité à venir, consultez l'excellent présentation sur les couches CSS par Bramus.

   Remarque : Veuillez vous assurer de consulter les ressources sur la fin de cet article pour quelques liens liés à la vérification de la spécificité CSS. D'après mon expérience, cela se produit souvent en raison du changement sous-jacent du DOM. Lorsque nous ajoutons du CSS basé sur le DOM actuel, notre solution n'est pas résiliente au changement.

   Par exemple, si nous créons une règle de mise en page de grille pour une liste définie comme .grid lipuis le La structure du DOM change pour devenir un ensemble d'éléments articlele CSS se brisera.

   Ou, si nous configurons une série d'icônes qui s'intègrent parfaitement dans l'espace d'origine, mais que le client doit alors ajouter une icône, et cela provoque un débordement.

   Ces exemples montrent vraiment pourquoi CSS est une compétence précieuse. Si vous pouvez écrire du CSS évolutif et indépendant du DOM, vos solutions évolueront et vous réduirez la probabilité de cette catégorie de bogues. les règles seront utilisées au-delà du problème actuel que vous résolvez.

   Le débogage de cette catégorie signifie généralement qu'il faut remonter aux règles d'origine pour voir si elles peuvent être étendues pour fonctionner pour le contexte mis à jour. Encore une fois, vous pouvez utiliser des outils de développement pour trouver les règles appliquées et même suivre le lien de référence pour accéder à la source.

   Remarque : Pour plus de conseils sur la façon de gérer cette catégorie avec des choses spécifiques à considérer, consultez mon article sur les styles CSS à l'épreuve du futur.

   Échanges de mise en page pour éviter les bogues CSS

   Regardons quelques exemples spécifiques qui peuvent provoquer des bogues de mise en page et comment les résoudre.

   Layout Spacing

   Une fois que flexbox a été introduit, de nombreuses solutions de mise en page de grille ont été publiées, qui avaient toutes des mathématiques pour calculer la largeur des enfants flex. De plus, cette largeur devait tenir compte de l'ajout de margin pour ajouter de l'espace entre les enfants.

   Bonne nouvelle : The gap La propriété pour flexbox est désormais prise en charge dans tous les navigateurs Evergreen !

   La grille CSS prend également en charge la propriété gap. L'avantage de gap par rapport à margin est qu'il ne s'appliquera toujours qu'entre éléments, quelle que soit l'orientation. Ainsi, plus besoin d'essayer d'attacher la marge du côté « correct » ou d'avoir à utiliser une marge négative sur le parent pour contrer la marge imbriquée.

   Contrairement à la margele l'utilisation de gap est moins susceptible de provoquer un débordement car il ne s'applique jamais au bord extérieur des éléments. Cependant, vous pouvez toujours rencontrer un débordement si les enfants ne peuvent pas redimensionner à une largeur plus étroite.

   Gestion des largeurs d'élément

   Si vos enfants flex ou grid provoquent un débordement, voici deux méthodes que vous pouvez essayer comme mises à niveau.

   Pour flex, assurez-vous d'utiliser flex-basis au lieu de width et que la valeur flex-shrink est définie sur 1. Ces propriétés garantiront que l'élément est autorisé à être réduit en taille. template-columns: repeat(auto-fit, minmax(30ch, 1fr));
   

   Mais, cela empêche les éléments de rétrécir en dessous de cette largeur minimale de 30ch. Ainsi, au lieu de cela, nous pouvons mettre à jour cette solution qui maintient notre minimum sur des fenêtres plus grandes/au sein de parents plus grands tout en permettant aux éléments enfants de se réduire dans des espaces plus étroits :

   grid-template-columns: repeat(auto-fit, minmax(min (100%, 30ch), 1fr));
   

   Je trouve souvent les fonctions CSS très utiles dans ce genre de scénarios. Si vous n'êtes pas familier, vous pouvez profiter de mon article sur les utilisations pratiques des fonctions CSS.

   En dehors d'un contexte de grille ou de flex, nous pouvons obtenir un comportement similaire pour les éléments afin d'éviter de définir une largeur absolue. Nous avons expliqué dans la section sur le débordement comment les valeurs absolues pouvaient souvent causer des problèmes. Mais, il y a, bien sûr, des moments où nous voulons fournir des paramètres de largeur.
   Once again, my preferred method for setting a flexible width uses the CSS function of min(). In this example, it is a bit of a shorthand for setting both width and max-width at once. The min() function will use the smaller computed value, which dynamically changes as the element’s context changes:

   width: min(100vw - 2rem, 80ch);
   

   The min() function accepts more than two values, so you could even add a percentage value here as well. Then, your container would be responsive not just to the viewport but when nested in other containers as well, reducing overflow bugs even further—and achieving our mission of creating scalable, DOM-independent styles!

   Review the use of min() as a container style as well as to make grid children more flexible in this CodePen:
   min() and CSS Grid for responsive containers (codepen.io)

   Cumulative Layout Shift

   A more recent hot topic in site performance and related metrics is Cumulative Layout Shift (CLS). This is the Google Lighthouse score for how much elements shift or jump during page load. Some offenders are pretty obvious, such as ads and popup banners. Those things use motion and are typically late or purposely delayed in loading.

   Now, before you go attacking the problem, make sure there is one. Chrome and Edge include the “Lighthouse” panel in dev tools which you can use to run a report for both desktop and mobile versions of your site. If CLS is not a problem, that score will be less than 0.1 and be displayed with a green indicator.

   

   Two other things that may affect your site are images and custom fonts.

   Fairly recently, all browsers have begun to reserve space for images if they include width and height attributes. Those attributes provide the two necessary pieces of information for the browser to calculate the image’s aspect ratio and hold that space within the page layout.

   However, due to responsive design, many of us are used to stripping those attributes assuming that CSS will take over. As Jen Simmons explainsit’s time to add those back in. In addition, you may need to tweak your responsive image CSS slightly to include the following somewhat more specific rule, which will allow the image to respond to narrower contexts without losing its aspect ratio:

   img[width] {
     height: auto;
   }
   

   As for custom fonts, the issue can come in here when the custom font and the designated system fallback font have a significant mismatch. In years past, we’d call it FLOUT (flash of unstyled text). This “flash” is from the delay in time between the initial page load and the custom font loading.

   In the example video from my own site that has this problem, I’ve used the Network Conditions panel in Edge to load the site with “Network throttling” set to “Slow 3G.”

   In my case, the actual CLS score doesn’t indicate the problem is severe enough to stress about resolving. However, if the font loading delay causes lots of elements to shift, that’s when it is worth looking into ways to alleviate the shifting problem.

   Sometimes you can select a fallback system font that better matches the custom font so that the relative size is a closer match. Or, you can reduce the effect by setting a minimum size on the parent elements or adjusting other layout attributes so that it doesn’t cause a significant shift when the font loads.

   Simon Hearne did a deep dive into what causes layout shifts due to fonts as well if you’d like to learn more about the problem, especially if you’re working on a more text-heavy site where the impact on CLS is more significant. They conclude that the ultimate solution to strictly address the layout shift is to use font-display: optional but concede that this is not optimal from a design perspective. Simon provides more solutions to help you select the right path for your site, including a handy CodePen to help you test fallbacks. Google also provides a resource describing preloading fonts.

   Resources For Debugging CSS

   We covered some frequent causes of CSS bugs and how to address them. Here are more resources that can help you with debugging CSS:

   Additionally, outside of the popular browser’s dev tools, you may find these two alternates helpful due to their extra tools and features:

   • Polypane (paid) is a browser that shows you multiple views of your site to test responsive design but also has additional features that can help you catch bugs early.
   • VisBug is a Chromium extension that gives you extra info about elements, which can also help pinpoint issues.
   (vf, il)