mars 19, 2019

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

À propos de l'auteur

Chris Ashton est un ingénieur logiciel senior travaillant pour BBC News. Quand il n’est pas occupé à coder, il aime chanter comme ténor dans le BBC Symphony Chorus.
Plus d'informations sur Chris …

IE8 a été publié aujourd'hui. Chris Ashton l'essaie contre le Web moderne et considère comment nous pouvons construire nos sites pour durer.

Cet article fait partie d'une série dans laquelle j'essaie d'utiliser le Web sous différentes contraintes, représentant un groupe démographique donné d'utilisateurs. J'espère mettre en évidence les difficultés rencontrées par de vraies personnes, qui sont évitables si nous concevons et développons nos ressources de manière à répondre à leurs besoins.

La dernière fois, j'ai navigué sur le Web pendant une journée en utilisant un écran lecteur . Cette fois-ci, j'ai passé la journée à utiliser Internet Explorer 8, publié le 19 mars 2009 aujourd'hui.

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 à supporter 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 de cesser d'utiliser Internet Explorer 11 .

Mais autant que nous, développeurs J'espère que ça s'en ira, c'est juste. Habitude. Die . IE8 continue de figurer dans les statistiques du navigateur, en particulier en dehors de la bulle du monde occidental.

Les statistiques du navigateur doivent être relevées avec une pincée de sel, mais les estimations actuelles de l’utilisation de IE8 dans le monde varient entre 0,3% et 0,4% du total. part de marché des ordinateurs de bureau. La partie inférieure de l'estimation provient de w3counter :

Graphique de l'utilisation de IE8 au fil du temps — D'un pic de près de 30% à la fin de 2010, W3Counter estime désormais que IE8 représente 0,3% de utilisation globale. ( Image agrandie )

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

Graphique de l'utilisation d'IE8 par rapport aux autres navigateurs — D'après StatCounter, l'utilisation mondiale de IE8 est de 0,37%. ( Grand aperçu )

J'imaginais que l'utilisation de IE8 serait plus importante dans certaines régions géographiques, de sorte que les données ont été analysées par continent.

Utilisation de IE8 par région

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

1. Océanie 0.09%

2. Europe 0.25%

3. Sud Amérique 0.30%

4. Amérique du Nord 0.35%

5. Afrique 0.48%

Asie

0.50% [19659037] Quelqu'un en Asie est cinq fois plus susceptible d'utiliser IE8 qu'un autre en Océanie.

J'ai examiné de plus près les statistiques asiatiques, en notant la proportion d'utilisation de IE8 dans chaque pays. Les six pays les mieux classés pour l'utilisation de IE8 sont ensuite comparables à la moyenne mondiale:

1.	Iran	3.99%
2.	Chine [19659020] 1.99%
3.	Corée du Nord	1.38%
4.	Turkménistan	1.31%
5.	Afghanistan	1.27%
6	Cambodge	1.05%
7.	Yémen	0.63%
8.	Taïwan	0.62%
9.	Pakistan	0.57%
10.	Bangladesh	0.54%

Ces données sont résumées sur le plan ci-dessous:

Graphique illustrant la répartition de IE8 en Asie — L'Iran, le Turkménistan et l'Afghanistan au Moyen-Orient, et la Chine, la Corée du Nord et le Cambodge en Extrême-Orient se distinguent par leur utilisation d'IE8. ( Grand aperçu )

Chose incroyable, IE8 représente environ 4% des utilisateurs d'ordinateurs de bureau en Iran – quarante fois la proportion d'utilisateurs d'IE8 en Océanie.

Ensuite, j'ai examiné dans les statistiques par pays pour l’Afrique, qui utilisait à peu près la même utilisation d’IE8 que l’Asie. Il y avait un gagnant clair (Érythrée), suivi d'un certain nombre de pays dépassant ou se situant autour de la marque d'utilisation à 1%:

1.	Érythrée	3.24%
2.	Botswana	1.37%
3.	Soudan et Sud-Soudan	1.33%
4.	Niger	1.29%
5.	Mozambique	1.19%
6.	Mauritanie	1.18%
7.	Guinée	1.12%
8.	République démocratique du Congo	1.07%
9. [19659020] Zambie	0,94%

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

Graphique illustrant la répartition de IE8 en Afrique — L’Érythrée se démarque par son utilisation de IE8 (3,24%). Un certain nombre d'autres pays ont également un taux d'utilisation> 1%. ( Grand aperçu )

Alors que les pays d’Asie où l’utilisation de IE8 est supérieure à la normale sont à peu près regroupés géographiquement, il ne semble pas exister de tendance en Afrique. La seule tendance que je puisse voir – à moins que ce soit une coïncidence – est qu'un certain nombre des plus grands pays utilisant IE8 au monde censément censuré l'accès à Internet, et par conséquent n'encouragent ni ne permettent probablement la mise à jour vers des navigateurs plus sécurisés.

destiné à un public purement occidental, vous ne vous soucierez probablement pas beaucoup de IE8. Toutefois, si vous avez un marché en plein essor en Asie ou en Afrique – et particulièrement si vous vous souciez des utilisateurs en Chine, en Iran ou en Érythrée – vous pouvez vous soucier de l’expérience IE8 de votre site Web. Oui, même en 2019!

Qui utilise encore IE?

Alors, qui sont ces personnes? Est-ce qu’ils marchent vraiment parmi nous?!

Qui qu’ils soient, vous pouvez parier qu’ils n’utilisent pas un ancien navigateur simplement pour vous embêter. Personne ne choisit délibérément une expérience de navigation pire.

Une personne pourrait utiliser un ancien navigateur pour les raisons suivantes:

Manque de connaissance
Ils ne savent simplement pas qu’ils utilisent une technologie obsolète.
Manque d’éducation
Ils ne connaissent pas les options de mise à niveau et les navigateurs de rechange qui s’offrent à eux.
Manque de planification
Rejeter les invites de mise à niveau car elles sont occupées, mais n’ont pas la prévoyance de procéder à une mise à niveau pendant les périodes plus calmes.
Aversion pour le changement
La dernière fois qu'ils ont mis à niveau leur logiciel, ils ont dû apprendre une nouvelle interface utilisateur. "Si ce n’est pas le cas, ne le corrigez pas."
Aversion pour le risque
La dernière fois qu'ils ont effectué une mise à niveau, leur ordinateur a ralenti à un rythme effréné ou ils ont perdu leur fonctionnalité préférée.
Limitation logicielle
Leur système d'exploitation est trop ancien pour les laisser 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 processeur.
Limitation de réseau
Une allocation de données limitée ou une connexion lente signifient qu'ils ne veulent pas télécharger 75 Mo de logiciel .
Limitation légale
Ils se trouvent peut-être sur une machine d'entreprise qui ne tolère que l'utilisation 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 placer dans le chaussures de l'une de ces âmes anonymes, et naviguer sur le Web pendant une journée en utilisant IE8. Vous pouvez jouer à la maison! Téléchargez une machine virtuelle «IE8 sur Windows 7» sur le site Web de Microsoft puis exécutez-la dans un virtualiseur du type VirtualBox .

IE8 VM: en route pour un mauvais départ

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

Capture d'écran de la page d'accueil par défaut d'IE8 non chargée — La première chose que j'ai vue était un 404. Génial. ( Grand aperçu )

Hmm, d'accord. On dirait que la page Web par défaut extraite par IE8 n'existe plus. Eh bien, ces chiffres. Microsoft a officiellement arrêté de prendre en charge IE8, alors pourquoi devrait-il s'assurer que la page de renvoi d'IE8 fonctionne toujours?

J'ai décidé de basculer sur le site le plus utilisé du monde.

Google

C’est un site simple, il est donc difficile de s’égarer – mais pour être juste, il est très beau! J'ai essayé de chercher quelque chose:

Capture d'écran des résultats de recherche Google pour Impractical Jokers — Ceux qui ont lu mes articles précédents peuvent remarquer un thème récurrent ici. ( Grand aperçu )

La recherche a bien fonctionné, même si la présentation est un peu différente de celle à laquelle je suis habitué. Puis, je me suis souvenu – j'avais vu la même présentation de résultats de recherche lorsque j'avais utilisé Internet pendant une journée avec JavaScript désactivé .

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

Capture d'écran des résultats de recherche Google Chrome pour Impractical Jokers — Mise en page plus propre, images supplémentaires et méta-informations, intégration Netflix / Twitter. ( Grand aperçu )

On dirait donc que IE8 obtient la version sans recherche d'écran JS de Google. Je ne pense pas que cela fût nécessairement une décision de conception délibérée – il se pourrait simplement que le code JavaScript soit erroné:

Capture d'écran de l'erreur de recherche Google "L'objet ne prend pas en charge cette propriété ou cette méthode" — La page a échoué. exécuter JavaScript. ( Grand aperçu )

Malgré tout, le résultat final me convient parfaitement – j'ai obtenu les résultats de ma recherche, ce qui est tout ce que je voulais.

J'ai cliqué pour visionner une vidéo YouTube.

YouTube

Il y a beaucoup de choses qui ne fonctionnent pas dans cette page. Tout cela a à voir avec les petites bizarreries dans IE.

Le logo, par exemple, est agrandi et recadré. Ceci est dû au fait que IE8 ne prend pas en charge SVG, et ce que nous constatons en réalité est l’option de secours fournie par YouTube. Ils ont appliqué une propriété CSS background-image afin que, en l’absence de prise en charge SVG, vous puissiez essayer d’afficher le logo. Seulement, ils semblent ne pas avoir réglé correctement la taille de l'arrière-plan . Il est donc un peu trop rapproché.

est définie par . ] background-img sur le logo span qui attire un sprite. ( Grand aperçu )

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

( Grand aperçu )

Et qu'en est-il de cette bascule Autoplay? La case est ressemblée étrangement:

Capture d'écran de la bascule Autoplay — On dirait que IE8 affiche par défaut une case à cocher sous le capot. ( Grand aperçu )

Cela semble résulter de l'utilisation d'un élément personnalisé (un bouton en papier à bascule qui est un élément de conception matérielle), ce que IE ne ' t comprendre:

Capture d’écran du balisage à bascule Autoplay — `Le bouton à bascule à papier` est un élément personnalisé. (La capture d'écran provient de Chrome DevTools, ainsi que de la façon dont la lecture automatique basculera DEVRAIT être rendue.) ( Grand aperçu )

Je ne suis pas surpris que cela ne soit pas 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

ou et il les convertira en div, mais en ignorant le style que vous leur appliquez.

Pour activer le balisage HTML5, vous devez indiquer explicitement au navigateur ces éléments. Elles peuvent ensuite être appelées comme suit:

Cela est enveloppé dans un IE conditionnel en passant.

This approach is a good one, provided you’re happy treating ES6 browsers as your new minimum baseline for functionality (~92% of global browsers at the time of writing).

However, just as the world of JavaScript is evolving, so is the world of CSS. Now that we have Grid, Flexbox, CSS variables and the like (each with a varying efficacy of fallback), there’s no telling what combination of CSS support an old browser might have that might lead to a mishmash of “modern” and “legacy” styling, the result of which looks broken. Therefore, sites are increasingly choosing to CTM their stylingso now HTML is the core baseline, and both CSS and JS are treated as enhancements.

The JavaScript-based CTM techniques we’ve seen so far have a couple of downsides if you use the presence of JavaScript to apply CSS in any way:

Inline JavaScript is blocking. Browsers must download, parse and execute your JavaScript before you get any styling. Therefore, users may see a flash of unstyled text.
Some users may have modern browsers, but choose to disable JavaScript. A JavaScript-based CTM prevents them from getting a styled site even when they’re perfectly capable of getting it.

The ‘ultimate’ approach is to use CSS media queries as your cuts-the-mustard litmus test. This “CSSCTM” technique is actively in use on sites such as Springer Nature.

This approach is quite brittle — accidentally overriding the clear property on your body selector would ‘break’ your site — but it does offer the best performance. This particular implementation uses media queries that are only supported in at least IE 9, iOS 7 and Android 4.4, which is quite a sensible modern baseline.

“Cuts the mustard”, in all its various guises, accomplishes two main principles:

Widespread user support;
Efficiently applied dev effort.

It’s simply not possible for sites to accommodate every single browser / operating system / network connection / user configuration combination. Techniques such as cuts-the-mustard help to rationalize browsers into C-grade and A-grade browsers, according to the Graded Browser Support model by Yahoo!.

Cuts-The-Mustard: An Anti-Pattern?

There is an argument that applying a global, binary decision of “core” vs “advanced” is not the best possible experience for our users. It provides sanity to an otherwise daunting technical problem, but what if a browser supports 90% of the features in your global CTM test, and this specific page doesn’t even make use of the 10% of the features it fails on? In this case, the user would get the core experience, since the CTM check would have failed. But we could have given them the full experience.

And what about cases where the given page does make use of a feature the browser doesn’t support? Well, in the move towards componentization, we could have a feature-specific fallback (or error boundary), rather than a page-level fallback.

We do this every day in our web development. Think of pulling in a web font; different browsers have different levels of font support. What do we do? We provide a few font file variations and let the browser decide which to download:

@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');
}

We have a similar fallback with HTML5 video. Modern browsers will choose which video format they want to use, whereas legacy browsers that don’t understand what a element is will simply render the fallback text:

The nesting approach we saw earlier used by the BBC for PNG fallbacks for SVG is the basis for the responsive image element. Modern browsers will render the best fitting image based on the media attribute supplied, whereas legacy browsers that don’t understand what a element is will render the fallback.

The HTML spec has carefully evolved over the years to provide a basic fallback mechanism for all browsers, whilst allowing features and optimisations for the modern browsers that understand them.

We could apply a similar principle to our JavaScript code. Imagine a Feature like so, where the foo method contains some complex JS:

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

  foo() {
    // etc
  }
}

export default new Feature();

Before calling foowe check if the Feature is supported in this browser by calling its browserSupported method. If it’s not supported, we don’t even attempt to call the code that would otherwise have errored our page.

import Feature from './feature';

if (Feature.browserSupported()) {
  Feature.foo();
}

This technique means we can avoid pulling in polyfills and just go with what’s natively supported by each individual browser, gracefully degrading individual features if unsupported.

Note that in the example above, I’m assuming the code gets transpiled to ES5 so that the syntax is understood by all browsers, but I’m not assuming that any of the code is polyfilled. If we wanted to avoid transpiling the code, we could apply the same principle but using the type="module" take on cuts-the-mustard, but it comes with the caveat that it already has a minimum ES6 browser requirement, so is only likely to start being a good solution in a couple of years:

We’ve covered HTML, and we’ve covered JavaScript. We can apply localized fallbacks in CSS too; there’s a @supports keyword in CSSwhich allows you to conditionally apply CSS based on the presence or absence of support for a CSS feature. However, it is ironically caveated with the fact that it is not universally supported. It just needs careful application; there’s a great Mozilla blog post on how to use feature queries in CSS.

In an ideal world, we shouldn’t need a global cuts-the-mustard check. Instead, each individual HTML, JS or CSS feature should be self-contained and have its own error boundaries. In a world of web components, shadow DOM and custom elements, I expect we’ll see more of a shift to this sort of approach. But it does make it much more difficult to predict and to test your site as a whole, and there may be unintended side-effects if, say, the styling of one component affects the layout of another.

Two Main Backwards Compatibility Strategies

A summary of polyfilling as a strategy:

✅ Can deliver client-side JS functionality to most users.
✅ Can be easier to code when delegating the problem of backwards-compatibility to a polyfill.
⚠️ Depending on implementation, could be detrimental to performance for users who don’t need polyfills.
⚠️ Depending on complexity of application and age of browser, may require lots of polyfills, and therefore run very poorly. We risk shipping megabytes of polyfills to the very browsers least prepared to accept it.

A summary of progressive enhancement as a strategy:

✅ Traditional CTM makes it easy to segment your code, and to manually test.
✅ Guaranteed baseline of experience for all users.
⚠️ Might unnecessarily deliver the core experience to users who could handle the advanced experience.
⚠️ Not well suited to sites that require client-side JS for functionality.
⚠️ Sometimes difficult to balance a robust progressive enhancement strategy with a performant first render. There’s a risk of over-prioritizing the ‘core’ experience to the detriment of the 90% of your users who get the ‘full’ experience (e.g. providing small images for noJS and then replacing with high-res images on lazy-load means we’ve wasted a lot of download capacity on assets that are never even viewed).

Conclusion

IE8 was once a cutting edge browser. (No, seriously.) The same could be said for Chrome and Firefox today.

If today’s websites are totally unusable in IE8, the websites in ten years time’ are likely to be about as unusable in today’s modern browsers — despite being built upon the open technologies of HTML, CSS, and JavaScript.

Stop and think about that for a moment. Isn’t it a bit scary? (That said, if you can’t abandon browsers after ten years and after the company who built it has deprecated it, when can you?)

IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.

We tend not to think about screen reader numbers. We simply take it for granted that it’s morally right to do our best to support users who have no other way of consuming our content, through no fault of our own. The same principle applies to people using older browsers.

We’ve covered some high-level strategies for building robust sites that should continue to work, to some degree, across a broad spectrum of legacy and modern browsers.

Once again, a disclaimer: don’t hack things for IE. That would be missing the point. But be mindful that all sorts of people use all sorts of browsers for all sorts of reasons, and that there are some solid engineering approaches we can take to make the web accessible for everyone.

Optimize for the majority, make an effort for the minority, and never sacrifice security.

Blog ARC Optimizer