Si vous avez une question à propos de cet article, n’hésitez pas à me contacter via Twitter: http://twitter.com/meulta

Le web est parti d’un rêve simple : partager. Partager de l’information, du contenu, des images, et plus tard des vidéos et des contenus plus riches. C’est pour cela que les langages du web ont toujours permis d’écrire du code une seule fois et le voir affiché agréablement sur tous les écrans du monde.

Afficher l'image d'origine

HTML, CSS, JavaScript et tous les langages et outils qui gravitent autour permettent de créer ce code qui fonctionnera sur tous les navigateurs de la planète.

La manière dont on écrit ce code a beaucoup évolué à travers le temps. A une certaine époque, tout le monde trouvait normal de faire de la mise en page en utilisant des tableaux. C’est une hérésie aujourd’hui, de nombreuses fonctionnalités HTML et CSS nous permettent de gérer la mise en page et la mise en forme d’un contenu de façon plus souple. Et pour JavaScript, on est passé en quelques années de code écrit exclusivement pas le développeur du site à une liste interminable de frameworks qu’il faut connaître, sélectionner et mettre à jour.

Depuis les années 90 le W3C est là pour définir les standards. Sa mission est principalement de permettre l’accès de l’information à tous. Il faut d’ailleurs voir ces standards comme des recommandations que l’on choisit de suivre ou pas. Cela a un côté parfois gênant puisqu’il est possible d’écrire du code pour le web qui fonctionnera parfaitement sans pour autant suivre toutes les recommandations d’accessibilité par exemple. On peut également créer un site web qui s’exécute correctement alors qu’il utilise une librairie JavaScript obsolète. Pire, on peut ne tester que sur un seul navigateur, et ne pas considérer les autres…

Un développeur web d’aujourd’hui doit avoir en tête un ensemble de bonne pratiques, qui lui permettent de façonner ses créations web comme un artisan cherche un juste équilibre entre le l’art et le côté pratique.

Nous avons essayé de regrouper un ensemble de bonnes pratiques à suivre comme une sorte de checklist. Pour cela, nous avons identifié 5 points distincts. Cette liste n’est évidemment pas exhaustive et n’hésitez pas à proposer des modifications ou ajout !

Pour vous éviter de devoir tout vérifier à la main, vous pouvez utiliser l’outil de scan disponible en ligne :

image

https://dev.windows.com/fr-fr/microsoft-edge/tools/staticscan/

Notez que si vous scannez mon blog vous allez trouver quelques erreurs 😉 La plateforme que nous utilisons est en cours de migration ça ne devrait plus être long ! 🙂

Vérification 1 : Est-ce que vous utilisez correctement les préfixes CSS ?

Le principe de CSS est très simple: on sélectionne un élément HTML et on y applique un style et des effets particuliers grâce à une liste de propriétés. Ces propriétés ne sont pas toujours finalisées et parfois, elle ne sont pas disponibles dans tous les navigateurs.

Généralement, elle sont implémentées dans un navigateur en premier et pour ne pas perturber les autres, un préfixe vendeur est utilisé. Par exemple, si Mozilla ajoute une propriété qui n’est pas encore standardisée, la mettre en oeuvre nécessitera d’utiliser le préfixe -moz-NOMDELAPROPRIETE. En faisant cela, le dev a conscience que ça ne fonctionnera que dans Firefox et qu’il faudra ajouter par la suite les propriétés -ms, -webkist, -o (pour Opéra), et finalement la version standardisée non préfixée quand chacun d’entre eux seront disponibles. Il faut toujours conserver l’intégralité des préfixes pour être certain que la propriété est appliquée dans le cas d’un navigateur un peu ancien qui ne supporterait pas encore la version non préfixée.

Le problème, c’est que bien souvent les développeurs ne précisent pas l’intégralité des préfixes. Ils se contentent souvent de -webkit. Et un navigateur a beau gérer une fonctionnalité, si on ne lui demande pas de l’utiliser, il ne l’utilisera pas. Et dans ce cas le site ne s’affichera pas correctement.

Même si nous continuons à expliquer cela à l’ensemble des développeurs dès que nous en avons l’occasion, nous avons décidé de corriger automatiquement ces erreurs dans Microsoft Edge dès que possible. Si on constate qu’une version préfixée est précisée mais que la version -ms n’est pas présente, nous l’ajoutons automatiquement avant d’interpréter la page. De cette manière, oublier un préfixe est moins gênant.

Essayez d’y faire attention quand même 😉

Vérification 2 : Générez-vous un contenu différent pour chaque navigateur ?

C’est un point très important. Par le passé il était fréquent de vérifier le navigateur qui demande d’afficher notre site web et de potentiellement réagir à cela en envoyer un balisage HTML (ou pire: un contenu) différent. C’est une pratique très peu adaptée dans le cadre du web moderne. Il vaut mieux envoyer le même code et le même contenu et tester la présence des fonctionnalités qu’on souhaite utiliser.

C’est un sujet très important car la détection de navigateur ne permet pas d’avoir un site web pérenne. Cela part d’une bonne idée: essayer de deviner les fonctionnalités qu’on peut utiliser en fonction de l’environnement dans lequel on est rendu. Mais comment gérer l’évolution des navigateurs ? Comment faire en sorte que dès qu’ils supportent ce qu’il ne supportaient pas avant, la version qui lui est dédiée l’utilise bien?

C’est exactement pour cela que l’on choisit maintenant de détecter la présence de la fonctionnalité plutôt que d’essayer de le deviner. A l’aide de JavaScript, on peut par exemple détecter dynamiquement que le stockage local est supporté. Si c’est le cas, parfait, utilisons-le ! Sinon, il faut trouver une alternative ou prévenir l’utilisateur qu’il n’aura pas accès à cette fonctionnalité.

Pour vous simplifier la vie et détecter facilement ce que le navigateur gère en termes de fonctionnalités web, vous pouvez utiliser une librairie telle que Modernizr.

Vérification 3: utilisez-vous des plugins ?

Le web est crossplateformes. C’est même certainement la technologie la plus crossplateformes au monde. Grâce à ça, un site web que vous écrivez pourra être exécuté sur une quantité incroyable de navigateurs et de périphériques.

Les plugins (activex, applet Java, etc.) ont été imaginées dans un monde ou accéder à un site web ne se faisait que sur desktop. Cela permettait notamment de combler facilement certains manques de la plateforme web. Quelque chose est impossible à faire en HTML ? Faisons un activeX ! JavaScript n’est pas assez performant ? Créons un applet Java !

Nous vivons désormais dans un monde ou HTML couplé à CSS est un langage extrêmement puissant, ou tout ou presque est possible. Nous vivons également dans un monde ou V8, le moteur JavaScript de Chrome ou Chakra, celui de Microsoft Edge atteignent des performances excellentes.

Plus de raisons dans ce cas d’utiliser des plugins. D’autant que ceux-ci ne sont pas accessibles et que leur contenu est très complexe à référencer.

C’est pour cette raison que le web moderne, dans notre esprit, est un web ne contenant aucun de ces plugins.

Vérification 4: Est-ce que vous avez mis à jour vos frameworks?

Le web est génial pour une raison simple: si vous voulez faire quelque chose il y a de fortes chances que quelqu’un l’a déjà fait avant vous. Et il y a même une probabilité qu’il ou elle ait packagé son code sous forme d’un framework réutilisable simplement.

Quand ces frameworks sont complexes comme par exemple jQuery, Angular.js ou React, ils sont mis à jour fréquemment. Au fil des versions, certaines fonctionnalités peuvent ne plus être supportées. Chaque framework a une liste de versions qui sont obsolètes.

C’est très important de s’assurer que l’on utilise bien des versions à jour de ces différents frameworks.

Vérification 5 : Est-ce que vous forcez une version particulière du moteur de rendu?

Depuis Internet Explorer 8 il est possible de choisir le mode de rendu de son site dans le navigateur. Le principe est très simple: vous ajoutez la balise x-ua-compatible et vous pouvez indiquer quel moteur doit être utilisé. Cela par d’une bonne intention : permettre à un développeur de ne pas avoir à changer son code à chaque fois qu’il y a une nouvelle version du navigateur.

Avec les versions modernes des navigateurs, il vaut mieux cependant ne pas fonctionner comme ça. Il est préférable de partir du principe que le navigateur va gérer correctement l’affichage du site et de lui faire confiance.

Pour pouvoir gérer la transition correctement, dans Microsoft Edge il y a désormais une valeur à ajouter au tag x-ua-compatible. Elle s’appelle « Edge » et elle permet de faire en sorte que dans le cas d’un navigateur moderne, le moteur utilisé soit le dernier. Vous pouvez temporairement conserver vos tags pour les anciens navigateurs si cela est vraiment nécessaire. Pensez à mettre à jour votre code rapidement cependant !

Si vous avez une question à propos de cet article, n’hésitez pas à me contacter via Twitter: http://twitter.com/meulta