J'ai utilisé le Web pendant une journée sur Internet Explorer 8

Cet article fait partie d'une série dans laquelle j'essaie d'utiliser le Web sous diverses contraintes, représentant un groupe démographique d'utilisateurs donné. J'espère rehausser le profil des difficultés rencontrées par de vraies personnes, qui sont évitables si nous concevons et développons d'une manière qui est sensible à leurs besoins.

La dernière fois, j'ai navigué sur le Web pendant une journée à l'aide d'un lecteur d'écran. Cette fois, j'ai passé la journée à utiliser Internet Explorer 8, sorti il ​​y a dix ans jour pour jour, le 19 mars 2009.

Qui dans le monde utilise IE8 ?

Avant de commencer; un avertissement : je ne suis pas sur le point de vous dire que vous devez commencer à prendre en charge IE8.

Il y a toutes les raisons de ne pas supporter IE8. Microsoft a officiellement cessé de prendre en charge IE8, IE9 et IE10 il y a plus de trois ans, et les dirigeants de Microsoft vous disent même d'arrêter d'utiliser Internet Explorer 11.

Mais autant que nous les développeurs espérons qu'il disparaisse, c'est juste. Habitude. Mourir . IE8 continue d'apparaître dans les statistiques des navigateurs, en particulier en dehors de la bulle du monde occidental.

Les statistiques du navigateur doivent être prises avec des pincettes, mais les estimations actuelles pour l'utilisation d'IE8 dans le monde sont d'environ 0,3 % à 0,4 % de la part de marché des ordinateurs de bureau. L'extrémité inférieure de l'estimation provient de w3counter :

L'estimation la plus élevée provient de StatCounter (le même flux de données utilisé par le tableau d'utilisation "Puis-je utiliser"). Il estime la proportion mondiale du navigateur de bureau IE8 à environ 0,37 %.

Je soupçonnais que nous pourrions voir une utilisation plus élevée d'IE8 dans certaines régions géographiques, donc explorées dans les données par continent.

Utilisation d'IE8 par région

Voici la proportion de postes de travail IE8 par continent (données de février 2018 à janvier 2019) :

Une personne en Asie est cinq fois plus susceptible d'utiliser IE8 qu'une personne en Océanie.

J'ai examiné de plus près les statistiques asiatiques, notant la proportion d'utilisation d'IE8 pour chaque pays. Il y a un top six très clair des pays pour l'utilisation d'IE8, après quoi les chiffres baissent pour être comparables à la moyenne mondiale :

Ces données sont résumées dans la carte ci-dessous :

Incroyablement, IE8 représente environ 4 % des utilisateurs de bureau en Iran, soit quarante fois la proportion d'utilisateurs d'IE8 en Océanie.

Ensuite, j'ai regardé les statistiques par pays pour l'Afrique, car elles avaient à peu près la même utilisation globale d'IE8 que l'Asie. Il y avait un gagnant clair (l'Érythrée), suivi par un certain nombre de pays au-dessus ou autour de la barre des 1 % d'utilisation :

Ceci est résumé dans la carte ci-dessous :

Alors que les pays d'Asie qui ont une utilisation IE8 supérieure à la normale sont à peu près regroupés géographiquement, il ne semble pas y avoir de modèle en Afrique. Le seul modèle que je peux voir - à moins que ce ne soit une coïncidence - est qu'un certain nombre des plus grands pays utilisant IE8 au monde censurent l'accès à Internet et n'encouragent ou n'autorisent donc probablement pas la mise à jour vers des navigateurs plus sécurisés.

Si votre site est destiné à un public purement occidental, il est peu probable que vous vous souciez beaucoup d'IE8. Si, toutefois, vous avez un marché asiatique ou africain en plein essor – et en particulier si vous vous souciez des utilisateurs en Chine, en Iran ou en Érythrée – vous pourriez très bien vous soucier de l'expérience IE8 de votre site Web. Oui — même en 2019 !

Qui utilise encore IE ?

Alors, qui sont ces gens ? Marchent-ils vraiment parmi nous ?!

Quels qu'ils soient, vous pouvez parier qu'ils n'utilisent pas un ancien navigateur juste pour vous ennuyer. Personne ne choisit délibérément une expérience de navigation pire.

Quelqu'un peut utiliser un ancien navigateur pour les raisons suivantes :

• Inconscient
  Ils ne savent tout simplement pas qu'ils utilisent une technologie obsolète.
• Manque d'éducation
  Ils ne connaissent pas les options de mise à niveau et les navigateurs alternatifs qui s'offrent à eux.
• Manque de planification
  Ignorer les invites de mise à niveau car elles sont occupées, mais n'ont pas la prévoyance de mettre à niveau pendant les périodes plus calmes.
• Aversion au changement
  La dernière fois qu'ils ont mis à jour leur logiciel, ils ont dû apprendre une nouvelle interface utilisateur. "Si ce n'est pas cassé, ne le répare pas."
• Aversion au risque
  La dernière fois qu'ils ont mis à niveau, leur machine a ralenti ou ils ont perdu leur fonctionnalité préférée.
• Limitation logicielle
  Leur système d'exploitation est trop ancien pour les mettre à niveau, ou leurs privilèges d'administrateur peuvent être verrouillés.
• Limitation matérielle
  Les nouveaux navigateurs sont généralement plus exigeants en termes d'espace disque, de mémoire et de CPU.
• Limitation du réseau
  Une allocation de données plafonnée ou une connexion lente signifie qu'ils ne veulent pas télécharger 75 Mo de logiciels.
• Limite légale
  Ils peuvent se trouver sur une machine d'entreprise qui ne tolère l'utilisation que d'un navigateur spécifique.

Est-ce vraiment une telle surprise qu'il y ait encore des gens dans le monde qui s'accrochent à IE8 ?

J'ai décidé de me mettre à la place de l'une de ces âmes anonymes et de naviguer sur le Web pendant une journée avec IE8. Vous pouvez jouer à la maison ! Téléchargez une machine virtuelle "IE8 sur Windows 7" à partir du site Web de Microsoft, puis exécutez-la dans un virtualiseur comme VirtualBox.

Machine virtuelle IE8 : un mauvais départ

J'ai démarré ma machine virtuelle IE8, cliqué sur le programme Internet Explorer en prévision, et voici ce que j'ai vu :

Hmm d'accord. On dirait que la page Web par défaut extraite par IE8 n'existe plus. Eh bien, ça compte. Microsoft a officiellement cessé de prendre en charge IE8, alors pourquoi devrait-il s'assurer que la page de destination IE8 fonctionne toujours ?

J'ai décidé de passer au site le plus utilisé au monde.

Google

C'est un site simple, donc difficile de se tromper — mais pour être honnête, il a fière allure ! J'ai essayé de chercher quelque chose :

La recherche a bien fonctionné, bien que la mise en page soit un peu différente de celle à laquelle je suis habitué. Puis je me suis souvenu - j'avais vu la même mise en page des résultats de recherche lorsque j'avais utilisé Internet pendant une journée avec JavaScript désactivé.

Pour référence, voici à quoi ressemblent les résultats de la recherche dans un navigateur moderne avec JavaScript activé :

Ainsi, il semble qu'IE8 obtienne la version sans JS de la recherche Google. Je ne pense pas que ce soit nécessairement une décision de conception délibérée - il se peut simplement que le JavaScript se soit trompé :

Pourtant, le résultat final me convient - j'ai obtenu mes résultats de recherche, c'est tout ce que je voulais.

J'ai cliqué dessus pour regarder une vidéo YouTube.

Youtube

Il y a pas mal de choses cassées sur cette page. Tout à voir avec de petites bizarreries dans IE.

Le logo, par exemple, est agrandi et recadré. Cela est dû au fait qu'IE8 ne prend pas en charge SVG, et ce que nous voyons en réalité, c'est l'option de secours fournie par YouTube. Ils ont appliqué une propriété CSS background-image afin qu'en cas de non prise en charge de SVG, vous ayez une tentative d'affichage du logo. Seulement, ils semblent ne pas avoir défini correctement la background-size , donc c'est un peu trop zoomé.

Pour référence, voici la même page dans Chrome (voir comment Chrome rend un SVG à la place) :

Et qu'en est-il de cette bascule de lecture automatique ? C'est rendu comme une case à cocher bizarre:

Cela semble être dû à l'utilisation d'un élément personnalisé (un bouton à bascule papier, qui est un élément Material Design), qu'IE ne comprend pas :

Je ne suis pas surpris que cela n'ait pas été rendu correctement; IE8 ne gère même pas le balisage sémantique de base que nous utilisons de nos jours. Essayez d'utiliser un <aside> ou <main> et cela les rendra essentiellement comme des divs, mais en ignorant tout style que vous leur appliquez.

Pour activer le balisage HTML5, vous devez indiquer explicitement au navigateur que ces éléments existent. Ils peuvent ensuite être stylisés comme d'habitude :

 <!--[if lt IE 9]> <script> document.createElement('header'); document.createElement('nav'); document.createElement('section'); document.createElement('article'); document.createElement('aside'); document.createElement('footer'); </script> <![endif]-->

Cela est enveloppé dans un conditionnel IE, soit dit en passant. <!--[if lt IE 9]> est un commentaire HTML pour la plupart des navigateurs - et est donc ignoré - mais dans IE, il s'agit d'une condition qui ne passe que "si inférieur à IE 9", où il exécute/rend les nœuds DOM à l'intérieur.

Ainsi, la page vidéo a été un échec. Visiter YouTube.com directement ne s'est pas beaucoup mieux passé :

Sans me décourager, j'ai ignoré l'avertissement et j'ai essayé de rechercher une vidéo dans la barre de recherche de YouTube.

Le trafic IE8 est clairement suffisamment suspect pour que YouTube n'ait pas cru que je suis un véritable utilisateur et a décidé de ne pas traiter ma demande de recherche !

Inscription à Gmail

Si je vais passer la journée sur IE8, je vais avoir besoin d'une adresse e-mail. Je vais donc essayer d'en créer un nouveau.

Tout d'abord, j'ai essayé Gmail.

Il y a quelque chose qui cloche dans l'image et le texte ici. Je pense que c'est dû au fait qu'IE8 ne prend pas en charge les requêtes multimédias - il essaie donc de me montrer une image mobile sur le bureau.

Une façon de contourner ce problème consiste à utiliser Sass pour générer deux feuilles de style ; un pour les navigateurs modernes et un pour les anciens IE. Vous pouvez obtenir un CSS compatible avec IE et adapté aux mobiles (voir le didacticiel de Jake Archibald) en utilisant un mixin pour vos requêtes multimédias. Le mixin "aplatit" votre CSS IE hérité pour traiter IE comme s'il s'agissait toujours d'une largeur prédéfinie spécifique (par exemple 65em), ne donnant que le CSS pertinent pour cette largeur. Dans ce cas, j'aurais vu l' background-image correcte pour ma taille d'écran supposée et j'aurais eu une meilleure expérience.

Quoi qu'il en soit, cela ne m'a pas empêché de cliquer sur "Créer un compte". Il y avait quelques différences entre son apparence dans IE8 et un navigateur moderne :

Bien que prometteur à première vue, le formulaire était assez bogué à remplir. Le "libellé" ne s'efface pas lorsque vous commencez à remplir les champs, de sorte que votre texte d'entrée est obscurci :

Le balisage de cette étiquette est en fait un <div> , et certains JS intelligents déplacent le texte lorsque l'entrée est focalisée. Le JS ne réussit pas sur IE8, donc le texte reste obstinément en place.

Après avoir rempli tous mes détails, j'ai cliqué sur "Suivant" et j'ai attendu. Rien ne s'est passé.

Ensuite, j'ai remarqué le petit symbole d'avertissement jaune en bas à gauche de ma fenêtre IE. J'ai cliqué dessus et j'ai vu qu'il se plaignait d'une erreur JS :

J'ai abandonné Gmail et je me suis tourné vers MSN.

Inscription à Hotmail

Je commençais à craindre que le courrier électronique ne soit interdit pour un navigateur de dix ans. Mais quand je suis allé sur Hotmail, le formulaire d'inscription avait l'air correct - jusqu'ici tout va bien :

Puis j'ai remarqué un CAPTCHA. J'ai pensé: "Il n'y a aucun moyen que je m'en sorte..."

À ma grande surprise, le CAPTCHA a fonctionné !

La seule chose bizarre sur le formulaire était un positionnement d'étiquette légèrement bogué, mais l'inscription était par ailleurs transparente :

Cette capture d'écran vous semble-t-elle correcte ? Pouvez-vous repérer l'erreur délibérée?

L'entrée la plus à gauche aurait dû être mon prénom , pas mon nom de famille. Lorsque je suis revenu et que j'ai vérifié cette page plus tard, j'ai cliqué sur l'étiquette "Prénom" et elle a appliqué le focus à l'entrée la plus à gauche, c'est ainsi que j'aurais pu vérifier que je remplissais la bonne case en premier lieu. Cela montre l'importance d'un balisage accessible - même sans CSS ni association visuelle, je pouvais déterminer exactement quelle zone de saisie s'appliquait à quelle étiquette (quoique la deuxième fois !).

Quoi qu'il en soit, j'ai pu terminer le processus d'inscription et j'ai été redirigé vers la page d'accueil de MSN, ce qui s'est bien passé.

Je pouvais même lire des articles et oublier que j'utilisais IE8 :

Avec mon e-mail enregistré, j'étais prêt à aller voir le reste d'Internet !

Facebook

J'ai visité le site Facebook et j'ai été immédiatement redirigé vers le site mobile :

Il s'agit d'une tactique de repli intelligente, car Facebook doit prendre en charge un large public mondial sur des appareils mobiles bas de gamme, il doit donc fournir une version de base de Facebook de toute façon. Pourquoi ne pas offrir la même base d'expérience aux anciens navigateurs de bureau ?

J'ai essayé de m'inscrire et j'ai pu créer un compte. Génial! Mais lorsque je me suis connecté à ce compte, j'ai été traité avec suspicion - tout comme lorsque j'ai cherché des choses sur YouTube - et j'ai été confronté à un CAPTCHA.

Seulement cette fois, ce n'était pas si facile.

J'ai essayé de demander de nouveaux codes et d'actualiser la page plusieurs fois, mais l'image CAPTCHA ne s'est jamais chargée, j'ai donc été effectivement verrouillé hors de mon compte.

Tant pis. Essayons d'autres médias sociaux.

Twitter

J'ai visité le site Twitter et j'ai eu exactement la même expérience de redirection mobile.

Mais je n'ai même pas pu aller jusqu'à créer un compte cette fois :

Curieusement, Twitter est heureux que vous vous connectiez, mais pas pour que vous vous inscriviez en premier lieu. Je ne sais pas pourquoi - peut-être qu'il a un scénario CAPTCHA similaire sur ses pages d'inscription qui ne fonctionnera pas sur les anciens navigateurs. De toute façon, je ne pourrai pas créer un nouveau compte.

Je me sentais mal à l'aise de me connecter avec mon compte Twitter existant. Appelez-moi paranoïaque, mais des vulnérabilités comme l'attaque CFR Watering Hole de 2013 - où le simple fait de visiter une URL spécifique dans IE8 installerait des logiciels malveillants sur votre machine - m'ont rendu nerveux à l'idée de compromettre mon compte.

Mais, dans un souci d'éducation, j'ai persévéré (avec un nouveau mot de passe temporaire) :

Je pourrais aussi tweeter, mais en utilisant le très basique <textarea> :

En conclusion, Twitter est fondamentalement bien dans IE8 - tant que vous avez déjà un compte !

J'en ai fini avec les réseaux sociaux pour la journée. Allons voir quelques nouvelles.

nouvelles de la BBC

La page d'accueil des actualités semble très basique et maladroite, mais fonctionne fondamentalement, mais avec des avertissements de sécurité de contenu mixte.

Jetez un œil au logo. Comme nous l'avons déjà vu sur YouTube, IE8 ne prend pas en charge SVG, nous avons donc besoin d'une solution de repli PNG.

La BBC utilise la technique de secours <image> pour afficher un PNG sur IE :

…et pour ignorer le PNG lorsque SVG est disponible :

Cette technique exploite le fait que les anciens navigateurs obéissaient à la fois aux balises <image> et <img> , et ignorent donc la <svg> inconnue et rendent la solution de secours, alors que les navigateurs modernes ignorent le rendu <image> lorsqu'ils sont à l'intérieur d'un SVG. Chris Coyier explique la technique plus en détail.

J'ai essayé de voir un article :

C'est lisible. Je peux voir le titre, la navigation, l'image sélectionnée. Mais le reste des images de l'article est manquant :

Ceci est à prévoir et est dû aux images de chargement paresseux de la BBC. IE8 n'étant pas un 'navigateur pris en charge' signifie qu'il n'obtient pas le JavaScript qui permet le chargement paresseux, ainsi les images ne se chargent jamais du tout.

Par intérêt, j'ai pensé voir ce qui se passerait si j'essayais d'accéder au BBC iPlayer :

Et cela m'a amené à m'interroger sur un autre service de streaming.

Netflix

Je m'attendais à moitié à une page blanche vide lorsque j'ai chargé Netflix dans IE8. J'ai été agréablement surpris quand j'ai vu une page de destination décente :

J'ai comparé cela avec la version moderne de Chrome :

Il y a un appel à l'action légèrement différent (texte du bouton) - probablement dû aux tests multivariés plutôt qu'au navigateur sur lequel je suis.

Ce qui est différent dans le rendu, c'est le texte centralisé et la superposition noire semi-transparente.

L'absence de texte centralisé est due à l'utilisation de Flexbox par Netflix pour aligner les éléments :

Un text-align: center sur cette classe corrigerait probablement le centrage pour IE8 (et en fait tous les anciens navigateurs). Pour une prise en charge maximale du navigateur, vous pouvez suivre une approche de secours CSS avec l'ancien CSS "sûr", puis resserrer les mises en page avec un CSS plus moderne pour les navigateurs qui le prennent en charge.

Le manque d'arrière-plan est dû à l'utilisation de rgba() , qui n'est pas pris en charge dans IE8 et inférieur.

Traditionnellement, il est bon de fournir des retours CSS comme celui-ci, qui affichent un arrière-plan noir pour les anciens navigateurs mais affichent un arrière-plan semi-transparent pour les navigateurs modernes :

 rgb(0, 0, 0); /* IE8 fallback */ rgba(0, 0, 0, 0.8);

Il s'agit d'un correctif très spécifique à IE, cependant, pratiquement tous les autres navigateurs prennent en charge rgba . De plus, dans ce cas, vous perdriez complètement les tuiles Netflix sophistiquées, il serait donc préférable de n'avoir aucun filtre d'arrière-plan du tout ! Le moyen infaillible d'assurer la prise en charge de plusieurs navigateurs serait d'intégrer le filtre dans l'image d'arrière-plan elle-même. Simple mais efficace.

Quoi qu'il en soit, jusqu'ici, tout va bien - IE8 a en fait rendu la page d'accueil assez bien! Est-ce que je vais réellement regarder Breaking Bad sur IE8 aujourd'hui ?

Mon optimisme déjà provisoire a été immédiatement abattu lorsque j'ai consulté la page de connexion :

Pourtant, j'ai pu me connecter et j'ai vu un tableau de bord épuré (pas de bandes-annonces fantaisistes à expansion automatique):

J'ai cliqué sur un programme avec une vague anticipation, mais bien sûr, je n'ai vu qu'un écran noir.

Amazone

Ok, les réseaux sociaux et la vidéo sont sortis. Il ne reste plus qu'à faire les courses.

J'ai vérifié Amazon et j'ai été époustouflé - c'est presque impossible à distinguer de l'expérience que vous obtiendriez dans un navigateur moderne :

J'ai déjà été attiré par une bonne page d'accueil. Alors cliquons sur une page de produit et voyons s'il ne s'agit que d'un coup de chance.

Non! La page produit avait l'air bien aussi!

Amazon n'était pas le seul site qui m'a surpris dans sa rétrocompatibilité. Wikipédia avait fière allure, tout comme le site Web du gouvernement britannique. Il n'est pas facile d'avoir un site qui ne ressemble pas à un véritable accident de voiture dans IE8. La plupart de mes expériences étaient décidément moins abouties…!

Mais un avis d'avertissement obsolète ou une mise en page funky n'était pas la pire chose que j'ai vue aujourd'hui.

Sites totalement cassés

Certains sites étaient tellement cassés que je ne pouvais même pas m'y connecter !

Je me demandais s'il s'agissait peut-être d'un problème temporaire de réseau de VM, mais cela se produisait à chaque fois que j'actualisais la page, même lorsque je revenais sur le même site plus tard dans la journée.

Cela s'est produit sur quelques sites différents tout au long de la journée, et j'ai finalement conclu que cela n'affectait jamais les sites sur HTTP - uniquement sur HTTPS (mais pas tous les sites HTTPS). Alors, quel était le problème?

En utilisant Wireshark pour analyser le trafic réseau, j'ai essayé de me connecter à nouveau à GitHub. Nous pouvons voir que la connexion n'a pas pu être établie en raison d'une erreur fatale, "Description : version du protocole".

En regardant les paramètres par défaut dans IE8, seul TLS 1.0 est activé, mais GitHub a abandonné la prise en charge de TLSv1 et TLSv1.1 en février 2018.

J'ai coché les cases pour TLS 1.1 et TLS 1.2, j'ai rechargé la page et - voilà ! — J'ai pu voir GitHub !

Un grand merci à mon ami extrêmement talentueux Aidan Fewster pour m'avoir aidé à déboguer ce problème.

Je suis tout à fait pour la rétrocompatibilité, mais cela présente un dilemme intéressant. Selon le Conseil des normes de sécurité PCI, TLS 1.0 n'est pas sécurisé et ne devrait plus être utilisé. Mais en forçant TLS 1.1 ou supérieur, certains utilisateurs seront invariablement bloqués (et tous ne seront probablement pas assez avertis pour activer TLS 1.2 dans leurs paramètres avancés).

En autorisant des normes plus anciennes et non sécurisées et en permettant aux utilisateurs de continuer à se connecter à nos sites, nous ne les aidons pas - nous leur nuisons, en ne leur donnant pas de raison de passer à des technologies plus sûres. Alors, jusqu'où devez-vous aller pour prendre en charge les anciens navigateurs ?

Comment puis-je commencer à prendre en charge les anciens navigateurs ?

Lorsque certaines personnes pensent à « prendre en charge les anciens navigateurs », elles pensent peut-être à ces anciens hacks propriétaires pour IE, comme cette fois où la BBC a dû faire des choses incroyablement difficiles pour prendre en charge le contenu iframed dans IE7.

Ou ils peuvent penser à faire fonctionner les choses dans le « mode bizarrerie » d'Internet Explorer ; un mode de fonctionnement spécifique à IE qui rend les choses très différentes des normes.

Mais « prendre en charge les anciens navigateurs » est très différent de « le pirater pour IE ». Je ne préconise pas ce dernier, mais nous devrions essayer pragmatiquement de faire le premier. Le mantra que j'essaie de suivre en tant que développeur Web est le suivant :

"Optimisez pour la majorité, faites un effort pour la minorité et ne sacrifiez jamais la sécurité."

Je vais maintenant m'éloigner du monde d'IE8 et parler de solutions générales et durables pour la prise en charge des navigateurs hérités.

Il existe deux stratégies générales pour prendre en charge les navigateurs plus anciens, commençant toutes deux par P :

1. Polyremplissage
   Efforcez-vous d'atteindre la parité des fonctionnalités pour tous en remplissant les fonctionnalités manquantes du navigateur.
2. Amélioration progressive
   Commencez par une expérience de base, puis utilisez la détection de fonctionnalités pour superposer les fonctionnalités.

Ces stratégies ne sont pas mutuellement exclusives ; ils peuvent être utilisés en tandem. Il y a un certain nombre de décisions de mise en œuvre à prendre dans l'une ou l'autre approche, chacune avec ses propres nuances, que je couvrirai plus en détail ci-dessous.

Polyremplissage

Pour certains sites Web ou pages Web, JavaScript est très important pour la fonctionnalité et vous souhaitez simplement fournir du JavaScript fonctionnel à autant de navigateurs que possible.

Il y a plusieurs façons de le faire, mais d'abord, une leçon d'histoire.

Une brève histoire d'ECMAScript

ECMAScript est une norme et JavaScript est une implémentation de cette norme. Cela signifie que ES5 est "ECMAScript version 5" et ES6 est "ECMAScript version 6". Confusément, ES2015 est le même que ES6.

ES6 était le nom popularisé de cette version avant sa sortie, mais ES2015 est le nom officiel, et les versions ECMAScript suivantes sont toutes associées à leur année de sortie.

Remarque : tout cela est utilement expliqué par Brandon Morelli dans un excellent article de blog qui explique l'historique complet des versions de JavaScript.

Au moment de la rédaction, la dernière norme est ES2018 (ES9). La plupart des navigateurs modernes prennent en charge au moins ES2015. Presque tous les navigateurs prennent en charge ES5.

Techniquement IE8 n'est pas ES5. Ce n'est même pas ES4 (qui n'existe pas — le projet a été abandonné). IE8 utilise l'implémentation Microsoft d'ECMAScript 3, appelée JScript. IE8 a une certaine prise en charge d'ES5 mais a été publié quelques mois avant la publication des normes ES5, et a donc une inadéquation de la prise en charge.

Transpiling vs Polyfilling

Vous pouvez écrire du JavaScript ES5 et il fonctionnera dans presque tous les anciens navigateurs :

 var foo = function () { return 'this is ES5!'; };

Vous pouvez également continuer à écrire tout votre JavaScript comme ça - pour activer la rétrocompatibilité pour toujours. Mais vous passeriez à côté des nouvelles fonctionnalités et du sucre syntaxique qui sont devenus disponibles dans les versions évolutives de JavaScript, vous permettant d'écrire des choses comme :

 const foo = () => { return 'this is ES6!'; };

Essayez d'exécuter ce JavaScript dans un navigateur plus ancien et il y aura une erreur. Nous devons transpiler le code dans une version antérieure de JavaScript que le navigateur comprendra (c'est-à-dire convertir notre code ES6 en ES5, à l'aide d'outils automatisés).

Supposons maintenant que notre code utilise une méthode ES5 standard, telle que Array.indexOf . La plupart des navigateurs ont une implémentation native de cela et fonctionneront bien, mais IE8 cassera. Rappelez-vous qu'IE8 a été publié quelques mois avant la publication des normes ES5, et qu'il y a donc une inadéquation de la prise en charge ? Un exemple de cela est la fonction indexOf , qui a été implémentée pour String mais pas pour Array .

Si nous essayons d'exécuter la méthode Array.indexOf dans IE8, cela échouera. Mais si nous écrivons déjà dans ES5, que pouvons-nous faire d'autre ?

Nous pouvons polyfill le comportement de la méthode manquante. Les développeurs remplissent traditionnellement chaque fonctionnalité dont ils ont besoin en copiant et collant du code ou en extrayant des bibliothèques de polyfill tierces externes. De nombreuses fonctionnalités JavaScript ont de bonnes implémentations polyfill sur leur page Mozilla MDN respective, mais il convient de souligner qu'il existe plusieurs façons de polyfill la même fonctionnalité.

Par exemple, pour vous assurer que vous pouvez utiliser la méthode Array.indexOf dans IE8, vous devez copier et coller un polyfill comme ceci :

 if (!Array.prototype.indexOf) { Array.prototype.indexOf = (function (Object, max, min) { // big chunk of code that replicates the behaviour in JavaScript goes here! // for full implementation, visit: // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexof#Polyfill })(Object, Math.max, Math.min); }

Tant que vous appelez le polyfill avant d'insérer l'un de vos propres JS, et à condition que vous n'utilisiez aucune fonctionnalité JavaScript ES5 autre que Array.indexOf , votre page fonctionnerait dans IE8.

Les polyfills peuvent être utilisés pour combler toutes sortes de fonctionnalités manquantes. Par exemple, il existe des polyfills pour activer les sélecteurs CSS3 tels que :last-child (non pris en charge dans IE8) ou l'attribut d' placeholder (non pris en charge dans IE9).

Les polyfills varient en taille et en efficacité et dépendent parfois de bibliothèques externes telles que jQuery.

Vous pouvez également entendre parler de "shims" plutôt que de "polyfills". Ne vous attardez pas trop sur la dénomination - les gens utilisent les deux termes de manière interchangeable. Mais techniquement parlant, un shim est un code qui intercepte un appel d'API et fournit une couche d'abstraction. Un polyfill est un type de shim , dans le navigateur . Il utilise spécifiquement JavaScript pour adapter les nouvelles fonctionnalités HTML/CSS/JS dans les anciens navigateurs.

Résumé de la stratégie "importation manuelle de polyfills" :

• Contrôle complet sur le choix des polyfills ;
• Convient aux sites Web de base ;
• ️ Sans outils supplémentaires, vous êtes obligé d'écrire en JavaScript natif ES5 ;
• ️ Difficile de microgérer tous vos polyfills ;
• ️ Prêt à l'emploi, tous vos utilisateurs recevront les polyfills, qu'ils en aient besoin ou non.

Babel Polyremplissage

J'ai parlé de transpiler le code ES6 vers ES5. Vous faites cela en utilisant un transpiler , dont le plus populaire est Babel.

Babel est paramétrable via un fichier .babelrc à la racine de votre projet. Dans celui-ci, vous pointez vers divers plugins et préréglages Babel. Il y en a généralement un pour chaque transformation de syntaxe et polyfill de navigateur dont vous aurez besoin.

La microgestion de ceux-ci et leur synchronisation avec la liste de prise en charge de votre navigateur peuvent être pénibles, de sorte que la configuration standard de nos jours consiste à déléguer cette microgestion au module @babel/preset-env. Avec cette configuration, vous donnez simplement à Babel une liste des versions de navigateur que vous souhaitez prendre en charge, et il fait le travail pour vous :

 { "presets": [ [ "@babel/preset-env", { "useBuiltIns": "usage", "targets": { "chrome": "58", "ie": "11" } } ] ] }

L'option de configuration useBuiltIns de @babel/preset-env est là où la magie opère, en combinaison avec un import "@babel/polyfill" (un autre module) dans le point d'entrée de votre application.

• Lorsqu'il est omis, useBuiltIns ne fait rien. L'intégralité de @babel/polyfill est incluse avec votre application, ce qui est assez lourd.
• Lorsqu'il est défini sur "entry" , il convertit l'importation @babel/polyfill en plusieurs importations plus petites, en important les polyfills minimum requis pour polyfill les navigateurs ciblés que vous avez répertoriés dans votre .babelrc (dans cet exemple, Chrome 58 et IE 11) .
• Le réglage sur "usage" va encore plus loin en effectuant une analyse de code et en important uniquement les polyfills pour les fonctionnalités qui sont réellement utilisées . Il est classé comme "expérimental" mais pèche par excès de "polyfill trop" plutôt que "trop ​​peu". Dans tous les cas, je ne vois pas comment il est possible que cela crée un paquet plus gros que "entry" ou false , c'est donc une bonne option à choisir (et c'est ainsi que nous allons à la BBC).

À l'aide de Babel, vous pouvez transpiler et remplir votre JavaScript avant de le déployer en production, et cibler la prise en charge dans une ligne de base minimale spécifique de navigateurs. NB, un autre outil populaire est TypeScript, qui possède son propre transpileur qui transpile vers ES3, prenant en charge en théorie IE8 prêt à l'emploi.

Résumé de l'utilisation de @babel/preset-env pour le polyfilling :

• Déléguer la microgestion des polyfills à un outil ;
• L'outil automatisé aide à empêcher l'inclusion de polyfills dont vous n'avez pas besoin ;
• S'adapte à des sites plus vastes et complexes ;
• ️ Prêt à l'emploi, tous vos utilisateurs recevront les polyfills, qu'ils en aient besoin ou non ;
• ️ Difficile de garder un œil sur ce qui est inséré dans votre bundle d'applications.

Chargement paresseux de polyfills avec Webpack et importations dynamiques

Il est possible de tirer parti de la nouvelle proposition import() pour détecter les fonctionnalités et télécharger dynamiquement les polyfills avant d'initialiser votre application. Cela ressemble à ceci dans la pratique:

 import app from './app.js'; const polyfills = []; if (!window.fetch) { polyfills.push(import(/* webpackChunkName: "polyfill-fetch" */ 'whatwg-fetch')); } Promise.all(polyfills) .then(app) .catch((error) => { console.error('Failed fetching polyfills', error); });

Cet exemple de code est copié sans vergogne du très bon article, "Lazy Loading Polyfills With Webpack And Dynamic Imports" qui approfondit la technique plus en détail.

Sommaire:

• Ne surcharge pas les navigateurs modernes avec des polyfills inutiles ;
• ️ Nécessite de gérer manuellement chaque polyfill.

polyfill.io

polyfill.io est le polyfilling en tant que service, construit par le Financial Times. Cela fonctionne par votre page en faisant une seule demande de script à polyfill.io, répertoriant éventuellement les fonctionnalités spécifiques dont vous avez besoin pour polyfill. Leur serveur analyse ensuite la chaîne de l'agent utilisateur et remplit le script en conséquence. Cela vous évite d'avoir à fournir manuellement vos propres solutions de polyfill.

Voici le JavaScript renvoyé par polyfill.io pour une requête effectuée depuis IE8 :

Voici la même requête polyfill.io, mais où la requête provenait de Chrome moderne :

Tout ce qui est requis de votre site est un appel de script unique.

Sommaire:

• Facilité d'inclusion dans votre application Web ;
• Délègue la responsabilité des connaissances polyfill à un tiers ;
• ️ D'un autre côté, vous dépendez désormais d'un service tiers ;
• ️ Effectue un appel <script> bloquant, même pour les navigateurs modernes qui n'ont pas besoin de polyfills.

Amélioration progressive

Le polyfilling est une technique incroyablement utile pour prendre en charge les anciens navigateurs, mais peut être un gonflement pour les pages Web et sa portée est limitée.

La technique d'amélioration progressive, en revanche, est un excellent moyen de garantir une expérience de base pour tous les navigateurs, tout en conservant toutes les fonctionnalités pour vos utilisateurs sur les navigateurs modernes. Cela devrait être réalisable sur la plupart des sites.

Le principe est le suivant : partir d'une base de HTML (et de style, facultatif), et « améliorer progressivement » la page avec la fonctionnalité JavaScript. L'avantage est que si le navigateur est un ancien, ou si le JavaScript est cassé à tout moment de sa livraison, votre site devrait toujours être fonctionnel.

Le terme "amélioration progressive" est souvent utilisé de manière interchangeable avec "JavaScript discret". Ils signifient essentiellement la même chose, mais ce dernier va un peu plus loin en ce sens que vous ne devriez pas encombrer votre HTML avec de nombreux attributs, identifiants et classes qui ne sont utilisés que par votre JavaScript.

Couper-La-Moutarde

La technique BBC de "couper la moutarde" (CTM) est une mise en œuvre éprouvée de l'amélioration progressive. Le principe est que vous écrivez une expérience de base solide de HTML, et avant de télécharger tout JavaScript amélioré, vous vérifiez un niveau minimum de support. L'implémentation d'origine vérifiait la présence de fonctionnalités HTML5 standard :

 if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // Enhance for HTML5 browsers }

Au fur et à mesure que de nouvelles fonctionnalités apparaissent et que les anciens navigateurs deviennent de plus en plus obsolètes, nos réductions de la ligne de base de la moutarde changeront. Par exemple, une nouvelle syntaxe JavaScript telle que les fonctions de flèche ES6 signifierait que cette vérification CTM en ligne ne parvient même pas à analyser dans les navigateurs hérités - même pas en s'exécutant en toute sécurité et en échouant la vérification CTM - peut donc avoir des effets secondaires inattendus tels que la rupture d'autres JavaScript tiers. (par exemple Google Analytics).

Pour éviter même d'essayer d'analyser du JS moderne non transpilé, nous pouvons appliquer cette "prise moderne" sur la technique CTM, tirée du blog de @snugug, dans laquelle nous profitons du fait que les anciens navigateurs ne comprennent pas le type="module" déclaration et la passera en toute sécurité. En revanche, les navigateurs modernes ignoreront les déclarations <script nomodule> .

 <script type="module" src="./mustard.js"></script> <script nomodule src="./no-mustard.js"></script> <!-- Can be done inline too --> <script type="module"> import mustard from './mustard.js'; </script> <script nomodule type="text/javascript"> console.log('No Mustard!'); </script>

Cette approche est bonne, à condition que vous acceptiez de traiter les navigateurs ES6 comme votre nouvelle base de référence minimale pour les fonctionnalités (~ 92 % des navigateurs mondiaux au moment de la rédaction).

Cependant, tout comme le monde de JavaScript évolue, le monde de CSS évolue également. Maintenant que nous avons Grid, Flexbox, les variables CSS et autres (chacune avec une efficacité de repli variable), on ne sait pas quelle combinaison de support CSS un ancien navigateur pourrait avoir qui pourrait conduire à un méli-mélo de "moderne" et "hérité" style, dont le résultat semble cassé. Par conséquent, les sites choisissent de plus en plus CTM pour leur style , donc maintenant HTML est la base de référence de base, et CSS et JS sont traités comme des améliorations.

Les techniques CTM basées sur JavaScript que nous avons vues jusqu'à présent présentent quelques inconvénients si vous utilisez la présence de JavaScript pour appliquer CSS de quelque manière que ce soit :

1. Le JavaScript en ligne bloque. Les navigateurs doivent télécharger, analyser et exécuter votre JavaScript avant d'obtenir un style. Par conséquent, les utilisateurs peuvent voir un éclair de texte sans style.
2. Certains utilisateurs peuvent avoir des navigateurs modernes, mais choisissent de désactiver JavaScript. Un CTM basé sur JavaScript les empêche d'obtenir un site stylisé même lorsqu'ils sont parfaitement capables de l'obtenir.

L'approche "ultime" consiste à utiliser les requêtes média CSS comme test décisif. Cette technique « CSSCTM » est activement utilisée sur des sites tels que Springer Nature.

 <head> <!-- CSS-based cuts-the-mustard --> <!-- IMPORTANT: the JS depends on having this rule somewhere in the CSS: `body { clear: both }` --> <link rel="stylesheet" href="mq-test.css" media="only screen and (min-resolution: 0.1dpcm), only screen and (-webkit-min-device-pixel-ratio:0) and (min-color-index:0)"> </head> <body> <!-- content here... --> <script> (function () { // wrap in an IIFE to prevent global scope pollution function isSupported () { var val = ''; if (window.getComputedStyle) { val = window.getComputedStyle(document.body, null).getPropertyValue('clear'); } else if (document.body.currentStyle) { val = document.body.currentStyle.clear; } if (val === 'both') { // references the `body { clear: both; }` in the CSS return true; } return false; } if (isSupported()) { // Load or run JavaScript for supported browsers here. } })(); </script> </body>

Cette approche est assez fragile - remplacer accidentellement la propriété clear de votre sélecteur de body "casserait" votre site - mais elle offre les meilleures performances. Cette implémentation particulière utilise des requêtes multimédias qui ne sont prises en charge qu'au moins dans IE 9, iOS 7 et Android 4.4, ce qui est une référence moderne assez sensible.

« Coupe la moutarde », sous toutes ses formes, accomplit deux grands principes :

1. Prise en charge étendue des utilisateurs ;
2. Effort de développement appliqué efficacement.

Il n'est tout simplement pas possible pour les sites de s'adapter à chaque combinaison de navigateur/système d'exploitation/connexion réseau/configuration utilisateur. Des techniques telles que les coupes à la moutarde aident à rationaliser les navigateurs en navigateurs de grade C et de grade A, selon le modèle Graded Browser Support de Yahoo! .

Coupe-La-Moutarde : Un Anti-Modèle ?

Il y a un argument selon lequel l'application d'une décision globale et binaire de "core" vs "avancé" n'est pas la meilleure expérience possible pour nos utilisateurs. Cela donne du bon sens à un problème technique autrement décourageant, mais que se passe-t-il si un navigateur prend en charge 90 % des fonctionnalités de votre test CTM global, et que cette page spécifique n'utilise même pas les 10 % des fonctionnalités sur lesquelles elle échoue ? Dans ce cas, l'utilisateur obtiendrait l'expérience de base, car la vérification CTM aurait échoué. Mais nous aurions pu leur donner l'expérience complète.

Et qu'en est-il des cas où la page donnée utilise une fonctionnalité que le navigateur ne prend pas en charge ? Eh bien, dans le mouvement vers la composition, nous pourrions avoir un repli spécifique à la fonctionnalité (ou limite d'erreur), plutôt qu'un repli au niveau de la page.

Nous le faisons tous les jours dans notre développement Web. Pensez à insérer une police Web ; différents navigateurs ont différents niveaux de prise en charge des polices. Qu'est-ce qu'on fait? Nous proposons quelques variantes de fichiers de polices et laissons le navigateur décider lequel télécharger :

 @font-face { font-family: FontName; src: url('path/filename.eot'); src: url('path/filename.eot?#iefix') format('embedded-opentype'), url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff'), url('path/filename.ttf') format('truetype'); }

Nous avons un repli similaire avec la vidéo HTML5. Les navigateurs modernes choisiront le format vidéo qu'ils souhaitent utiliser, tandis que les navigateurs hérités qui ne comprennent pas ce qu'est un élément <video> rendront simplement le texte de secours :

 <video width="400" controls> <source src="mov_bbb.mp4" type="video/mp4"> <source src="mov_bbb.ogg" type="video/ogg"> Your browser does not support HTML5 video. </video>

L'approche d'imbrication que nous avons vue précédemment utilisée par la BBC pour les replis PNG pour SVG est la base de l'élément d'image réactive <picture> . Les navigateurs modernes restitueront l'image la mieux adaptée en fonction de l'attribut media fourni, tandis que les navigateurs hérités qui ne comprennent pas ce qu'est un élément <picture> rendront l'élément <img> de secours.

 <picture> <source media="(min-width: 650px)"> <source media="(min-width: 465px)"> <img src="img_orange_flowers.jpg" alt="Flowers"> </picture>

La spécification HTML a soigneusement évolué au fil des ans pour fournir un mécanisme de secours de base pour tous les navigateurs, tout en permettant des fonctionnalités et des optimisations pour les navigateurs modernes qui les comprennent.

Nous pourrions appliquer un principe similaire à notre code JavaScript. Imaginez une fonctionnalité comme celle-ci, où la méthode foo contient du JS complexe :

 class Feature { browserSupported() { return ('querySelector' in document); // internal cuts-the-mustard goes here } foo() { // etc } } export default new Feature();

Avant d'appeler foo , nous vérifions si la fonctionnalité est prise en charge dans ce navigateur en appelant sa méthode browserSupported . S'il n'est pas pris en charge, nous n'essayons même pas d'appeler le code qui, autrement, aurait généré une erreur sur notre page.

 import Feature from './feature'; if (Feature.browserSupported()) { Feature.foo(); }

Cette technique signifie que nous pouvons éviter d'insérer des polyfills et simplement utiliser ce qui est pris en charge nativement par chaque navigateur individuel, dégradant gracieusement les fonctionnalités individuelles si elles ne sont pas prises en charge.

Notez que dans l'exemple ci-dessus, je suppose que le code est transpilé vers ES5 afin que la syntaxe soit comprise par tous les navigateurs, mais je ne suppose pas qu'aucun code n'est polyfilled . Si nous voulions éviter de transpiler le code, nous pourrions appliquer le même principe mais en utilisant le type="module" prendre des coupes-la-moutarde, mais il vient avec la mise en garde qu'il a déjà une exigence minimale de navigateur ES6, donc seulement susceptible de commencer à être une bonne solution dans quelques années :

 <script type="module"> import Feature from './feature.js'; if (Feature.browserSupported()) { Feature.foo(); } </script>

Nous avons couvert HTML, et nous avons couvert JavaScript. Nous pouvons également appliquer des replis localisés en CSS ; il existe un mot-clé @supports dans CSS, qui vous permet d'appliquer CSS de manière conditionnelle en fonction de la présence ou de l'absence de prise en charge d'une fonctionnalité CSS. Cependant, il est ironiquement mis en garde avec le fait qu'il n'est pas universellement pris en charge. Il a juste besoin d'une application minutieuse; il existe un excellent article de blog Mozilla sur l'utilisation des requêtes de fonctionnalités dans CSS.

Dans un monde idéal, nous ne devrions pas avoir besoin d'un contrôle mondial de la moutarde. Au lieu de cela, chaque fonctionnalité HTML, JS ou CSS doit être autonome et avoir ses propres limites d'erreur. Dans un monde de composants Web, de shadow DOM et d'éléments personnalisés, je m'attends à ce que nous assistions à une évolution vers ce type d'approche. Mais cela rend beaucoup plus difficile la prédiction et le test de votre site dans son ensemble, et il peut y avoir des effets secondaires imprévus si, par exemple, le style d'un composant affecte la mise en page d'un autre.

Deux principales stratégies de rétrocompatibilité

Un résumé du polyfilling comme stratégie :

• Peut fournir des fonctionnalités JS côté client à la plupart des utilisateurs.
• Peut être plus facile à coder en déléguant le problème de rétrocompatibilité à un polyfill.
• ️ Selon l'implémentation, cela pourrait nuire aux performances des utilisateurs qui n'ont pas besoin de polyfills.
• ️ Selon la complexité de l'application et l'âge du navigateur, cela peut nécessiter beaucoup de polyfills et donc fonctionner très mal. Nous risquons d'expédier des mégaoctets de polyfills aux navigateurs les moins préparés à l'accepter.

Un résumé de l'amélioration progressive en tant que stratégie :

• Le CTM traditionnel facilite la segmentation de votre code et le test manuel.
• Base d'expérience garantie pour tous les utilisateurs.
• ️ Peut offrir inutilement l'expérience de base aux utilisateurs qui pourraient gérer l'expérience avancée.
• ️ Pas bien adapté aux sites qui nécessitent JS côté client pour la fonctionnalité.
• ️ Parfois difficile d'équilibrer une stratégie d'amélioration progressive robuste avec un premier rendu performant. Il y a un risque de donner trop de priorité à l'expérience "de base" au détriment des 90 % de vos utilisateurs qui obtiennent l'expérience "complète" (par exemple, fournir de petites images pour noJS, puis les remplacer par des images haute résolution sur lazy-load signifie que nous 'ai gaspillé beaucoup de capacité de téléchargement sur des actifs qui ne sont même jamais consultés).

Conclusion

IE8 était autrefois un navigateur de pointe. (Non, sérieusement.) La même chose pourrait être dite pour Chrome et Firefox aujourd'hui.

Si les sites Web d'aujourd'hui sont totalement inutilisables dans IE8, les sites Web dans dix ans seront probablement à peu près aussi inutilisables dans les navigateurs modernes d'aujourd'hui, même s'ils reposent sur les technologies ouvertes HTML, CSS et JavaScript.

Arrêtez-vous et pensez-y un instant. N'est-ce pas un peu effrayant? (Cela dit, si vous ne pouvez pas abandonner les navigateurs après dix ans et après que l'entreprise qui l'a construit l'a rendu obsolète, quand le pourrez-vous ?)

IE8 est le bouc émissaire d'aujourd'hui. Demain ce sera IE9, l'année prochaine ce sera Safari, un an plus tard ce sera peut-être Chrome. Vous pouvez remplacer IE8 par "l'ancien navigateur de votre choix". Le fait est qu'il y aura toujours un fossé entre ce pour quoi les développeurs de navigateurs construisent et les navigateurs que les gens utilisent. Nous devrions arrêter de nous moquer de cela et commencer à investir dans des solutions d'ingénierie robustes et inclusives . Les effets secondaires de ces stratégies ont tendance à rapporter des dividendes en termes d'accessibilité, de performances et de résilience du réseau, il y a donc une vue d'ensemble en jeu ici.

Nous avons tendance à ne pas penser aux numéros de lecteur d'écran. Nous tenons tout simplement pour acquis qu'il est moralement juste de faire de notre mieux pour aider les utilisateurs qui n'ont pas d'autre moyen de consommer notre contenu, sans faute de notre part. Le même principe s'applique aux personnes utilisant des navigateurs plus anciens.

Nous avons couvert certaines stratégies de haut niveau pour créer des sites robustes qui devraient continuer à fonctionner, dans une certaine mesure, sur un large éventail de navigateurs anciens et modernes.

Encore une fois, un avertissement : ne piratez rien pour IE. Ce serait passer à côté de l'essentiel. Mais gardez à l'esprit que toutes sortes de personnes utilisent toutes sortes de navigateurs pour toutes sortes de raisons, et qu'il existe des approches techniques solides que nous pouvons adopter pour rendre le Web accessible à tous.

Optimisez pour la majorité, faites un effort pour la minorité et ne sacrifiez jamais la sécurité.

Lectures complémentaires sur SmashingMag :

• Normes Web : le quoi, le pourquoi et le comment
• Regroupement intelligent : comment servir le code hérité uniquement aux navigateurs hérités
• N'utilisez pas l'attribut d'espace réservé
• Concevoir pour un Web sans navigateur