Fermer

février 4, 2019

Guide de prise en charge CSS dans les navigateurs


À propos de l'auteur

Rachel Andrew est non seulement la rédactrice en chef de Smashing Magazine, mais également une développeuse Web, une écrivaine et une conférencière. Elle est l'auteur de plusieurs livres, notamment…
Pour en savoir plus sur Rachel

Cela peut être frustrant de vouloir utiliser une fonctionnalité et découvrir qu'elle n'est pas prise en charge ou se comporte différemment selon les navigateurs. Dans cet article, Rachel Andrew détaille les différents types de problèmes liés à la prise en charge des navigateurs et montre l’évolution de CSS pour faciliter leur traitement.

Nous ne vivrons jamais dans un monde où tous les utilisateurs de nos sites ont un navigateur et une version de navigateur identiques, tout comme nous ne vivrons jamais dans un monde où tout le monde a la même taille d'écran et de résolution. Cela signifie que s’occuper d’anciens navigateurs – ou de navigateurs qui ne prennent pas en charge quelque chose que nous souhaitons utiliser – fait partie du travail d’un développeur Web. Cela dit, les choses vont beaucoup mieux maintenant que par le passé et, dans cet article, je vais passer en revue les différents types de problèmes de prise en charge des navigateurs que nous pourrions rencontrer. Je vais vous montrer quelques moyens de les résoudre, ainsi que des solutions susceptibles de vous aider.

Pourquoi avons-nous ces différences?

Même dans un monde où la majorité des navigateurs sont compatibles. sont basés sur Chromium, ces navigateurs n’exécutent pas tous la même version de Chromium que Google Chrome. Cela signifie qu'un navigateur basé sur Chrome, tel que Vivaldi, pourrait être quelques versions derrière Google Chrome.

Et, bien sûr, les utilisateurs ne mettent pas toujours à jour rapidement leurs navigateurs, bien que cette situation se soit améliorée ces dernières années, la plupart des navigateurs restant silencieux.

Il y a aussi la manière dont les nouvelles fonctionnalités entrent dans les navigateurs en premier lieu. Les nouvelles fonctionnalités pour CSS ne sont pas conçues par le groupe de travail CSS, et une spécification complète est transmise aux éditeurs de navigateurs avec une instruction pour la mettre en œuvre. Très souvent, ce n’est que lorsqu’une implémentation expérimentale est réalisée que tous les détails les plus fins de la spécification peuvent être élaborés. Par conséquent, le développement des fonctionnalités est un processus itératif et nécessite que les navigateurs implémentent ces spécifications en développement. Bien que la mise en œuvre se fasse le plus souvent de nos jours derrière un drapeau dans le navigateur ou disponible uniquement dans une version nocturne ou une version d’aperçu, une fois qu'un navigateur a une fonctionnalité complète, il est susceptible de l’activer pour tout le monde, même si aucun autre navigateur n’a encore de support. 19659007] Tout cela signifie que, même si nous l'aimons bien, nous n'existerons jamais dans un monde où les fonctions sont disponibles comme par magie simultanément sur tous les ordinateurs et téléphones. Si vous êtes un développeur Web professionnel, votre travail consiste à traiter ce problème.

Bugs vs Lack Of Support

Nous sommes confrontés à trois problèmes. en ce qui concerne la prise en charge du navigateur:

  1. Absence de prise en charge d'une fonctionnalité
    Le premier problème (et le plus facile à traiter) concerne les situations dans lesquelles un navigateur ne prend pas en charge la fonctionnalité.
  2. Gestion des «bogues» du navigateur [19659014] Ensuite, le navigateur prétend prendre en charge la fonctionnalité, mais d’une manière différente de celle des autres navigateurs. Un tel problème est ce que nous avons tendance à appeler un «bogue de navigateur» car le résultat final est un comportement incohérent.
  3. Prise en charge partielle des propriétés CSS
    Celle-ci est en train de devenir plus courante; une situation dans laquelle un navigateur prend en charge une fonctionnalité – mais dans un seul contexte.

Il est utile de comprendre à quoi vous faites face lorsque vous voyez une différence entre les navigateurs, alors examinons tour à tour chacune de ces questions. 19659020] 1. Pas de prise en charge d'une fonctionnalité

Si vous utilisez une propriété CSS ou une valeur qu'un navigateur ne comprend pas, le navigateur l'ignorera. Il en va de même si vous utilisez une fonctionnalité non prise en charge ou si vous créez une fonctionnalité et essayez de l'utiliser. Si le navigateur ne comprend pas cette ligne de code CSS, il la saute simplement et passe à autre chose qu'il comprend.

Ce principe de conception de CSS signifie que vous pouvez utiliser avec joie les nouvelles fonctionnalités tout en sachant que rien ne sera mal arriver à un navigateur qui n'a pas de support. Pour certains CSS, utilisés uniquement à titre d'amélioration, c'est tout ce que vous devez faire. Utilisez la fonctionnalité, assurez-vous que lorsque cette fonctionnalité n'est pas disponible, l'expérience est toujours bonne, et c'est tout. Cette approche est l’idée de base de l’amélioration progressive en utilisant cette fonctionnalité de la plate-forme qui permet d’utiliser en toute sécurité les nouveaux éléments des navigateurs qui ne les comprennent pas.

Si vous souhaitez vérifier si une fonctionnalité que vous utilisez est prise en charge par navigateurs, vous pouvez consulter le site Web Can I Use . La page de chaque propriété CSS sur MDN est un autre bon endroit pour rechercher des informations de support détaillées. Les données de support du navigateur y ont tendance à être très détaillées.

Le nouveau CSS comprend le vieux CSS

À mesure que de nouvelles fonctionnalités CSS sont développées, une attention particulière est portée à la manière dont elles interagissent avec le CSS existant. Par exemple, dans les spécifications Grid et Flexbox, il est décrit en détail comment display: grid et display: flex traitent de scénarios tels que lorsqu'un élément flottant devient un élément de grille, ou un conteneur multicol est transformé en une grille. Cela signifie que certains comportements sont ignorés, ce qui vous aide simplement à écraser le code CSS du navigateur sans prise en charge. Ces substitutions sont détaillées dans la page pour Amélioration progressive et disposition de la grille sur MDN .

Détection de la prise en charge avec des requêtes d'entités

La méthode ci-dessus ne fonctionne que si le CSS que vous devez utiliser ne nécessite pas d'autres propriétés. aller avec elle. Vous devrez peut-être ajouter des propriétés supplémentaires à votre CSS pour les navigateurs plus anciens, qui seront ensuite interprétées par les navigateurs prenant également en charge la fonctionnalité.

Vous pouvez en trouver un bon exemple lorsque vous utilisez Grid Layout. Tandis qu'un élément flottant qui devient un élément de grille perd son comportement, il est probable que si vous essayez de créer un repli pour une présentation de grille avec flottant, vous aurez ajouté des largeurs en pourcentage et éventuellement des marges aux éléments.

. grid> .item {
    largeur: 23%;
    marge: 0 1%;
}

 Une mise en page à quatre colonnes
Les flotteurs permettent de créer une mise en page à quatre colonnes. Les largeurs et les marges doivent être définies dans % . ( Grand aperçu )

Ces largeurs et marges s'appliqueront toujours lorsque l'élément flottant est un élément de grille. La largeur devient un pourcentage du tracé de la grille plutôt que la largeur totale du conteneur; toute marge sera alors appliquée ainsi qu'un espace que vous pourriez avoir spécifié.

 .grid> .item {
    largeur: 23%;
    marge: 0 1%;
}

.la grille {
    affichage: grille;
    Grille-modèle-colonnes: 1fr 1fr 1fr 1fr;
    écart de colonne: 1%;
}

 Disposition de quatre colonnes avec des colonnes écrasées
La largeur correspond maintenant à un pourcentage du tracé de la grille – et non du conteneur. ( Grand aperçu )

Heureusement, une fonctionnalité intégrée à CSS et implémentée dans les navigateurs modernes nous aide à faire face à cette situation. Les requêtes de fonctionnalités nous permettent de demander directement au navigateur ce qu'elles prennent en charge, puis d'agir sur la réponse. Tout comme une requête multimédia – qui teste certaines propriétés du périphérique ou de l'écran – les requêtes de fonctions testent la prise en charge d'une propriété et d'une valeur CSS.

Test For Support

Le test de prise en charge est le cas le plus simple, nous utilisons ] @supports puis testez une propriété et une valeur CSS. Le contenu de la requête de fonctionnalité ne sera exécuté que si le navigateur répond par true, c’est-à-dire qu’il prend en charge la fonctionnalité.

Test d’absence de prise en charge

Vous pouvez demander au navigateur s’il ne prend pas en charge une fonctionnalité. Dans ce cas, le code de la requête de fonctionnalité ne sera exécuté que si le navigateur indique qu'il ne prend pas en charge.

 @supports not (display: grid) {
    .article {
        / * CSS des navigateurs ne supportant pas la disposition en grille * /
    }
}
Testez plusieurs choses

Si vous avez besoin de plusieurs propriétés, utilisez et .

 @supports (display: grid) et (shape-outside: circle ()) {
    .article {
        / * CSS des navigateurs prenant en charge les formes de grille et CSS * /
    }
}

Si vous avez besoin de l’aide d’une propriété ou d’une autre, utilisez ou .

 @supports (display: grid) ou (display: flex) {
    .article {
        / * CSS des navigateurs prenant en charge grid ou flexbox * /
    }
}
Choisir une propriété et une valeur à tester

Il n’est pas nécessaire de tester chaque propriété que vous souhaitez utiliser – il s’agit simplement d’un élément qui indiquerait la prise en charge des fonctionnalités que vous envisagez d’utiliser. Par conséquent, si vous souhaitez utiliser la disposition de la grille, vous pouvez tester l'affichage : grid . À l'avenir (et une fois que le support de sous-réseau sera dans les navigateurs), vous devrez peut-être être plus spécifique et tester la fonctionnalité de sous-réseau. Dans ce cas, vous testeriez grid-template-columns: sous-grille pour obtenir une réponse vraie uniquement des navigateurs ayant implémenté le support de sous-réseau.

Si nous revenons maintenant à notre exemple de repli flottant, nous peut voir comment les requêtes de fonctionnalités vont résoudre ce problème pour nous. Ce que nous devons faire, c'est interroger le navigateur pour savoir s'il prend en charge la disposition de la grille. Si tel est le cas, nous pouvons définir la largeur de l'article sur auto et la marge sur 0 .

 .grid> .item {
    largeur: 23%;
    marge: 0 1%;
}

@supports (display: grid) {
    .la grille {
        affichage: grille;
        Grille-modèle-colonnes: 1fr 1fr 1fr 1fr;
        écart de colonne: 1%;
    }

    .grid> .item {
        largeur: auto;
        marge: 0;
    }
}

Notez que bien que j’aie inclus tout le code de grille dans ma requête de fonctionnalité, je n’ai pas besoin de le faire. Si un navigateur ne comprenait pas les propriétés de la grille, il les ignorerait pour pouvoir être en toute sécurité en dehors de la requête. Les éléments qui doivent figurer dans une requête de fonctionnalité dans cet exemple sont les propriétés margin et width, car elles sont nécessaires pour l'ancien code de navigateur mais seraient également appliquées par les navigateurs de support.

Embrace The Cascade

Un moyen très simple. offrir des solutions de repli consiste à utiliser le fait que les navigateurs ignorent les CSS qu'ils ne comprennent pas et le fait que, là où tout le reste a la même spécificité, l'ordre des sources est pris en compte en fonction de l'application de la CSS à un élément.

Vous écrivez d’abord votre CSS pour les navigateurs qui ne supportent pas cette fonctionnalité. Testez ensuite la prise en charge de la propriété que vous souhaitez utiliser, si le navigateur confirme sa prise en charge, écrasez le code de secours par votre nouveau code.

Cette procédure est à peu près la même que celle que vous pouvez utiliser lorsque vous utilisez des requêtes de support pour une conception sensible, à la suite de une approche mobile d'abord. Dans cette approche, vous commencez avec votre disposition pour les écrans plus petits, puis ajoutez ou écrasez les éléments pour les plus grands en remontant vos points d'arrêt.

Puis-je utiliser des requêtes d'entités CSS? Données sur la prise en charge des requêtes d'entités CSS dans les principaux navigateurs de caniuse.com.

La ​​méthode de travail ci-dessus vous évite de vous inquiéter des navigateurs qui ne prennent pas en charge les requêtes de fonctions. Comme vous pouvez le voir dans puis-je utiliser les requêtes de fonctions bénéficient d'un support considérable? Les navigateurs hors-ligne qui ne les prennent pas en charge n’appartenant à aucune version d’Internet Explorer.

Il est toutefois probable que la nouvelle fonctionnalité que vous souhaitez utiliser ne soit également pas prise en charge dans IE. Donc, à l’heure actuelle, vous commencerez presque toujours par écrire du CSS pour les navigateurs sans support, puis vous testerez avec une requête de fonctionnalité. Cette requête de fonctionnalité doit tester pour la prise en charge de .

  1. Les navigateurs prenant en charge les requêtes de fonctionnalités renvoient la valeur true si elles disposent de la prise en charge. Le code contenu dans la requête sera donc utilisé, ce qui remplacera le code des navigateurs plus anciens. Si le navigateur prend en charge les requêtes de fonctionnalités mais pas la fonctionnalité en cours de test, il renvoie false. Le code dans la requête de fonctionnalité sera ignoré.
  2. Si le navigateur ne prend pas en charge les requêtes de fonctionnalité, tout le contenu du bloc de requête de fonctionnalité sera ignoré, ce qui signifie qu'un navigateur tel que IE11 utilisera votre ancien code de navigateur, ce qui est très simple. probablement exactement ce que vous voulez!

2. Traiter les «bogues» du navigateur

Heureusement, le deuxième problème de prise en charge du navigateur devient de moins en moins courant. Si vous lisez « Ce que nous souhaitions » (publié à la fin de l’année dernière), vous pourrez vous faire un petit tour d’horizon des bugs les plus déconcertants des navigateurs du passé. Cela dit, tout logiciel est susceptible d’avoir des bugs, les navigateurs ne faisant pas exception. Et, si nous ajoutons à cela le fait qu'en raison de la nature circulaire de la mise en œuvre des spécifications, un navigateur implémente quelque chose, puis les spécifications changent, de sorte qu'il doit maintenant publier une mise à jour. Jusqu'à ce que cette mise à jour soit livrée, nous pourrions nous trouver dans une situation où les navigateurs font des choses différentes les uns des autres.

Les requêtes de fonctionnalités ne peuvent pas nous aider si le navigateur signale que quelque chose le soutient. Il n’existe aucun mode permettant au navigateur de dire: « Oui, mais vous n’aimerez probablement pas cela ." Lorsqu'un bogue d’interopérabilité apparaît, c’est dans ces situations que vous devrez peut-être être un un peu plus de créativité.

Si vous pensez voir un bogue, la première chose à faire est de le confirmer. Parfois, lorsque nous pensons avoir un comportement buggé et que les navigateurs font des choses différentes, la faute incombe à nous. Peut-être avons-nous utilisé une syntaxe non valide ou essayons-nous de styler du HTML mal formé? Dans ces cas, le navigateur essaiera de faire quelque chose; Cependant, comme vous n’utilisez pas les langues telles qu’elles ont été conçues, chaque navigateur peut faire face de manière différente. Une rapide vérification de la validité de vos codes HTML et CSS constitue une excellente première étape.

À ce stade, je ferais probablement une recherche rapide pour voir si mon problème était déjà bien compris. Il existe certains dépôts de problèmes connus, par exemple. Flexbugs et Gridbugs . Cependant, même quelques mots-clés bien choisis peuvent activer les articles ou articles de Stack Overflow qui traitent du sujet et peuvent vous donner une solution de contournement.

Mais supposons que vous ne sachiez pas vraiment ce qui est à l'origine du bogue, ce qui le rend mal à l'aise. assez difficile de chercher une solution. L’étape suivante consiste donc à créer un scénario de test réduit de votre problème, c’est-à-dire à éliminer tout élément inutile pour vous aider à identifier exactement ce qui déclenche le bogue. Si vous pensez que vous avez un bogue CSS, pouvez-vous supprimer du code JavaScript ou recréer le même style en dehors d'un cadre? J'utilise souvent CodePen pour créer ensemble un cas de test réduit de quelque chose que je vois; cela a aussi l'avantage de me donner le code d'une manière que je puisse facilement partager avec quelqu'un si j'ai besoin de poser des questions à ce sujet.

La ​​plupart du temps, une fois que vous avez isolé le problème, il est possible de autre moyen d’atteindre le résultat souhaité. Vous constaterez que quelqu'un d'autre a mis au point une solution de rechange astucieuse ou vous pouvez poster quelque part pour demander des suggestions.

Cela dit, si vous pensez que vous avez un bogue dans le navigateur et que vous ne trouvez personne d'autre qui parle de la même chose. problème, il est fort possible que vous ayez trouvé quelque chose de nouveau à signaler. Avec tous les nouveaux CSS qui ont atterri récemment, des problèmes peuvent parfois apparaître lorsque les gens commencent à utiliser des éléments en combinaison avec d'autres parties du CSS.

Découvrez ce message de Lea Verou qui explique comment signaler de tels problèmes, « Aide La communauté! Rapporter les bugs du navigateur! ”. L'article propose également d'excellents conseils pour créer un cas de test réduit.

3. Prise en charge partielle des propriétés CSS

Le troisième type de problème est devenu plus courant en raison de la conception des spécifications CSS modernes. Si nous pensons à la disposition de la grille et à la Flexbox, ces spécifications utilisent les propriétés et les valeurs du niveau d’alignement des cases 3 pour effectuer l’alignement. Par conséquent, des propriétés telles que align-items justification-contenu et intervalle de colonne sont spécifiées pour être utilisées à la fois dans Grid et Flexbox, ainsi que dans d'autres présentations méthodes.

Au moment de la rédaction du présent document, toutefois, les propriétés de l'intervalle fonctionnaient dans Grid Layout sous tous les navigateurs prenant en charge la grille et de column-gap dans Multicol; cependant, seul Firefox a implémenté ces propriétés pour Flexbox.

Si je devais utiliser les marges pour créer un repli pour Flexbox, puis tester column-gap et supprimer les marges, mes boîtes n'auraient plus d'espace. entre eux dans les navigateurs qui prennent en charge column-gap dans Grid ou multicol, mon espacement de repli sera donc supprimé.

 @supports (column-gap: 20px) {
    .flex {
        marge: 0; / * presque tout supporte les écarts de colonnes, donc cela supprimera toujours les marges, même si nous ne prenons pas en charge les espaces dans flexbox. * /
    }
}

Il s'agit d'une limitation actuelle des requêtes de fonctions. Nous n'avons aucun moyen de tester la prise en charge d'une fonctionnalité dans une autre fonctionnalité. Dans la situation ci-dessus, ce que je veux demander au navigateur est la suivante: «Avez-vous une prise en charge de l'écart de colonne dans Flexbox?». Ainsi, je peux obtenir une réponse négative pour pouvoir utiliser ma solution de repli.

problème avec les propriétés de fragmentation CSS de rupture de résistance après et de protection . Comme ceux-ci bénéficient d'un meilleur support lors de l'impression de la page, les navigateurs le demandent souvent. Toutefois, si vous testez la prise en charge de multicol, vous obtenez ce qui semble être des faux positifs. J'ai soulevé une question au sein du groupe de travail CSS pour cette question mais ce n'est pas un problème simple à résoudre. Si vous avez des idées, ajoutez-les-y.

Test de la prise en charge du sélecteur

Actuellement, les requêtes d'entités ne peuvent tester que les propriétés et les valeurs CSS. Une autre chose à tester est le support des sélecteurs plus récents, tels que ceux du niveau 4 de la spécification des sélecteurs. Il y a une note d'explication et également une implémentation derrière un drapeau dans Firefox Nightly d'une nouvelle fonctionnalité pour les requêtes d'objets permettant d'y parvenir.

Si vous visitez à propos de: config dans Firefox et activez l'indicateur layout.css.supports-selector.enabled pour pouvoir tester si différents sélecteurs sont pris en charge. La syntaxe est actuellement très simple, par exemple pour tester le sélecteur : has :

 @supports selector (: has) {
  .article {
      / * CSS pour le support de: has * /
  }
}

Ceci est une spécification en cours de développement, mais vous pouvez voir comment des fonctionnalités nous permettant d'aider à gérer les problèmes toujours présents de la prise en charge des navigateurs sont ajoutées au moment où nous parlons.

Pour en savoir plus

souhaitez utiliser une fonctionnalité et découvrir qu'elle n'est pas prise en charge par un seul navigateur principal ou si les choses semblent se comporter de différentes manières. J'ai rassemblé quelques lectures pratiques qui pourraient aider.

 Editorial Smashing (il)




Source link