Amélioration progressive avec JavaScript

Vous avez probablement entendu la phrase « le pouvoir corrompt ». La citation est plus longue, mais pour nos besoins, contentons-nous de ces deux mots. JavaScript est un outil incroyablement puissant et a été une force de corruption sur le web pendant trop longtemps. Il a généré des voies sans issue, des messages d'erreur et beaucoup trop de fenêtres pop-up pour les internautes. Il a aussi été largement incompris, ce qui a probablement contribué à ces abus, et sa pratique était apparentée à un art obscur.

Non seulement le JavaScript faisait plus de mal que de bien, mais il était aussi devenu dissipé. Sous la surface, c'était un sac de nœuds qui avait poussé tout le monde sauf les plus déterminés à s'enfuir en criant ; la maintenance était un cauchemar à cause de la prolifération de code dupliqué alambiqué et souvent énigmatique.

À l'époque, le JavaScript était vraiment laid par nécessité : les navigateurs n'avaient pas encore mis en œuvre de support décent des standards et les développeurs étaient occupés à écrire du code spaghetti en HTML. Le JavaScript a dû franchir beaucoup d'obstacles pour tout faire avec une compatibilité multinavigateur, même pour quelque chose d'aussi simple qu'un survol d'image.

Heureusement, nous sommes mieux placés sur les deux plans aujourd'hui et nous pouvons rendre notre JavaScript beaucoup plus propre. Cependant, nous devons respecter son pouvoir et agir de façon responsable. Nous devons autant nous préoccuper de la façon d'utiliser le JavaScript que de ce qu'il peut faire et peut-être même plus. Nous devons faire preuve de retenue. L'amélioration progressive nous aide dans cette voie, puisqu'elle nous oblige à nous concentrer sur le contenu et à construire à partir de lui.

Avec l'amélioration progressive, nous construisons des sites à partir de code fonctionnel. Le concept clé de JavaScript à garder à l'esprit est que tout le contenu dont les utilisateurs ont besoin pour comprendre le sens de la page doit exister dans cette page même en l'absence de script côté client. Point.

Exemple : peut-être le contenu en question est-il un tableau comparatif des produits que vous vendez. Si les exigences du site imposent des données triables par colonne, vous pouvez envisager de charger le tableau dans la page via AJAX, de façon à pouvoir le retrier côté serveur à tout moment. Ca a l'air parfait, non ?

Non.

Que se passe-t-il si des clients potentiels visitent la page sans JavaScript activé ? Si le contenu est chargé dans la page en utilisant JavaScript, ils n'ont pas accès à ce contenu, même dans son état non trié. Quelle probabilité pensez-vous qu'ils ont de passer une commande s'ils ne voient même pas les produits ?

Le scénario ci-dessus n'aborde même pas les conséquences sur les recherches. Les moteurs de recherche n'exécutent pas le JavaScript, donc si vous utilisez du JavaScript pour charger du contenu dans votre page, ils ne liront et n'indexeront jamais votre contenu. Combien de clients potentiels perdrez-vous si les informations sur vos produits ne peuvent pas être trouvées et indexées par Google, Microsoft ou Yahoo ?

En abordant les mêmes exigences avec l'amélioration progressive à l'esprit, vous devez inclure le tableau de base dans la page. Dans la majorité des cas, il peut toujours être généré par un module serveur, mais il doit être intégré directement dans la page plutôt que chargé via AJAX. Vous pouvez toujours écrire un script pour trouver le tableau dans le DOM et le rendre interactif, en générant des liens de tri et en liant leurs événements onclick à des appels AJAX pour une version retriée du tableau.

En abordant le défi de cette manière, non seulement vous répondez aux besoins, mais vous avez aussi fourni une expérience « basse qualité » pour les moteurs de recherche et les utilisateurs sans JavaScript.

En allant un peu plus loin, vous pourriez même manuellement ajouter les liens de tri dans les en-têtes du tableau et leur faire rafraîchir la page, en passant des paramètres pour retrier le tableau en conséquence. Cela permettrait à des utilisateurs sans JavaScript de retrier également les données, et leur donnerait une expérience « haute-qualité » un peu moins réactive, mais toujours pleinement fonctionnelle.

Quelques petites modifications dans votre script vous permettront de détourner ces liens pour effectuer des demandes AJAX comme avant, offrant les meilleures fonctionnalités aux utilisateurs les supportant. Finalement, vous avez un parfait exemple de l'amélioration progressive en action.

Maintenant que vous avez une compréhension de base de l'amélioration progressive avec JavaScript, nous pouvons parler de quelques techniques que vous pouvez utiliser pour commencer.

Une des clés de l'intégration efficace de l'amélioration progressive est d'établir un plan de gestion des scripts. Pour ce faire, vous devez commencer par vous familiariser avec le concept de « JavaScript non intrusif ». Le JavaScript non intrusif est la base de l'amélioration progressive dans le monde des scripts côté client.

Le moyen le plus évident de devenir « non intrusif » consiste à supprimer tous les gestionnaires d'événements en ligne, puisqu'ils peuvent facilement être enregistrés via le DOM :

<!--
<a href="http://msdn.com" onclick="return newWin(this.href);"> -->
<a href="http://msdn.com">

L'étape suivante consiste à déplacer tous vos scripts vers des fichiers externes liés, plutôt que les intégrer dans des éléments script :

<!--
<script type="text/javascript">
  // mon script
</script> -->
<script type="text/javascript" src="monscript.js"></script>

Cela les rendra plus faciles à maintenir et vous permettra des économies d'échelle. (Pour être honnête, ces deux modifications peuvent demander un peu de travail, puisque beaucoup d'éditeurs WYSIWIG et de frameworks de développement d'applications web génèrent par défaut du JavaScript horriblement intrusif. Heureusement, il existe des patchs et des add-ons que vous pouvez utiliser dans beaucoup de ces systèmes pour surmonter leurs mauvaises habitudes.)

L'étape suivante pour rendre vos scripts non intrusifs est de décider quand et où les inclure. Avec du bon sens, ça signifie vérifier que vous pouvez vraiment exécuter le script dans le navigateur de l'utilisateur en testant le support d'une méthode avant de l'appeler :

if( document.getElementById ){
  scriptUsingGetElementById();
}

Vous voudrez aussi tester tous les objets que vous utilisez et vous voudrez même tester l'existence des éléments identifiés nécessaires à votre script. Suivre ce procédé pour chaque script utilisé créera une interaction à la carte dans laquelle seuls les scripts qu'un navigateur peut gérer, et qui peuvent tourner sur le balisage de la page actuelle, seront exécutés.

Pour aller plus loin sur le JavaScript non intrusif, vous pouvez consulter l'article de Jeremy Keith à ce sujet.

JavaScript n'existe pas dans le vide, donc de la même façon que vous devez maintenir une séparation de vos scripts et de votre balisage (comme vu ci-dessus), vous devez maintenir une séparation entre vos scripts et vos styles.

Vous devez essentiellement arrêter d'ajouter des styles en ligne quand vous créez ou manipulez des éléments du DOM. À la place, appliquez des noms de classe qui se rapportent soit à votre feuille de style globale, soit à une feuille de style spécifique des scripts :

var el = document.getElementById( 'message' );
//el.style.color = '#f00';
//el.style.backgroundColor = '#ffcfcf';
el.className = 'highlighted';

Une feuille de style spécifique pour les scripts est une excellente option si votre script nécessite de nombreux styles pour activer son interactivité. La mettre en place dans son propre fichier permet de la maintenir indépendamment des autres styles du site. Cela vous donne aussi la possibilité de ne lier cette feuille de style que si votre script est exécuté, ce qui réduit le temps de chargement des pages qui n'utilisent pas le script ou des navigateurs qui ne le supportent pas.

Si vous décidez d'inclure vos styles dans une de vos feuilles de style principales, soyez certain de les écrire de telle façon qu'ils ne soient appliqués que quand le script s'est déroulé correctement.

Pour en savoir plus sur la séparation des styles et scripts, vous devriez lire cet article de la première publication de Scroll.

Nous avons passé en revue l'état d'esprit à avoir pour implémenter l'amélioration progressive en JavaScript et plusieurs techniques pour y parvenir. Nous avons aussi abordé le concept de script non intrusif et appris un peu comment gérer les relations entre CSS et JavaScript.

Cet article achève notre série d'introduction à l'amélioration progressive et sur la façon de la mettre en œuvre dans nos implémentations de CSS et JavaScript. Nous espérons qu'elle vous aura donné matière à réflexion et qu'elle vous incitera à utiliser l'amélioration progressive dans votre propre travail.

Tous mes remerciements à Diane Ménard et Kerod pour leur relecture !