Chapitre 11: Programmation Web : un cours condensé

Vous lisez probablement ceci dans un navigateur web, donc vous êtes susceptible d’être au moins un peu familier avec le World Wide Web. Ce chapitre contient une rapide et superficielle introduction aux différents éléments qui font fonctionner la toile, et la manière dont ils sont liés au JavaScript. Les trois suivants sont plus pratiques et présentent certaines des manières avec lesquelles JavaScript peut-être utilisé pour inspecter et changer une page web.

L’Internet est fondamentalement un simple réseau d’ordinateurs couvrant l’essentiel du monde. Les réseaux d’ordinateurs permettent aux ordinateurs de s’envoyer des messages les uns aux autres. Les techniques qui sont à la base de la mise en réseau sont un sujet intéressant mais pas le propos de ce livre. Tout ce que vous avez à savoir est que, généralement, un ordinateur, que nous appellerons serveur, attend que d’autres ordinateurs se mettent à lui parler. Une fois qu’un autre ordinateur, le client, ouvre une communication avec ce serveur, ils vont échanger ce qui a besoin d’être échangé en utilisant un langage spécifique, un protocole.

L’Internet est utilisé pour transporter des messages pour nombre de différents protocoles. Il y a des protocoles pour chatter, des protocoles pour l’échange de fichiers, des protocoles utilisés par des logiciels malicieux afin de contrôler l’ordinateur du pauvre schnock qui les a installés et ainsi de suite. Le protocole qui nous intéresse est celui qu’on utilise pour le World Wide Web. Il s’appelle HTTP, ce qui signifie Hyper Text Transfer Protocol (Protocole de Transfert Hyper Texte) et il sert à retrouver des pages web et les fichiers qui leur sont associés.

En communication HTTP, le serveur est l’ordinateur sur lequel la page web est conservée. Le client est un ordinateur, comme le vôtre, qui demande une page au serveur, afin de pouvoir l’afficher. Demander une page ainsi s’appelle une « requête HTTP ».

Les pages web et autres fichiers qui sont accessibles à travers l’Internet sont identifiés par des « URL », ce qui est une abréviation pour Universal Resource Locators (Localisateurs de Ressource Universel). Une URL ressemble à ceci:

http://acc6.its.brooklyn.cuny.edu/~phalsall/texts/taote-v3.html

Elle est composée de trois parties. Le début, http://, indique que cette URL utilise le protocole HTTP. Il y a d’autres protocoles, comme le FTP (File Transfer Protocol ou Protocole de Transfert de Fichiers), qui utilisent eux aussi des URL. La partie suivante, acc6.its.brooklyn.cuny.edu, nomme le serveur sur lequel cette page peut-être trouvée. La fin de l’URL, /~phalsal/texts/taote-v3.html, nomme le fichier spécifique sur ce serveur.

La plupart du temps, le World Wide Web est accessible grâce à un navigateur. Après avoir tapé une URL ou cliqué un lien, le navigateur fait la requête HTTP appropriée au serveur adéquat. Si tout se passe bien, le serveur répond en renvoyant un ficher au navigateur, qui le montre à l’utilisateur d’une façon ou d’une autre.

Quand, comme dans l’exemple, le fichier retrouvé est un document HTML, il sera affiché comme une page web. Nous avons brièvement discuté d’HTML dans le chapitre 6, où nous avons vu qu’il pouvait référencer des fichiers image. Dans le chapitre 9, nous avons trouvé que les pages HTML peuvent contenir la balise <script> pour charger des fichiers de code JavaScript. Quand un document HTML s’affiche, un navigateur récupère tous ces fichiers supplémentaires depuis leur serveur, de manière à les ajouter au document.

Bien qu’une URL soit supposée pointer sur un fichier, il est possible qu’un serveur web fasse quelque chose de plus compliqué que simplement rechercher un ficher et l’envoyer au client. ― Il peut traiter ce fichier d’une certaine manière en premier, ou peut-être n’y a-t-il pas du tout de fichier, mais seulement un programme qui, quand on lui donne une URL, a une façon de générer le document pertinent pour elle.

Des programmes qui transforment ou génèrent des documents sur un serveur sont une façon populaire de rendre les pages web moins statiques. Quand un fichier est juste un fichier, il est toujours le même, mais quand il y a un programme pour le fabriquer chaque fois qu’il est demandé, il peut être fait pour sembler différent à chaque utilisateur, en fonction de son identification et de ses préférences. Cela peut aussi rendre la gestion de contenu sur les pages web bien plus simple ― au lieu d’ajouter un nouveau fichier HTML chaque fois que quelque chose de nouveau est placé sur un site web, un nouveau document est stocké dans un entrepôt central et le programme sait où le trouver et comment le montrer aux clients.

Ce type de programmation web s’appelle programmation côté serveur. Cela affecte le document avant qu’il ne soit envoyé à l’utilisateur. Dans certains cas, il est pratique d’avoir un programme qui tourne après que la page a été envoyée, quand l’utilisateur la regarde. Ceci s’appelle programmation côté client, car le programme tourne sur l’ordinateur du client. La programmation web côté client est ce pour quoi JavaScript a été inventé.

Faire tourner des programmes côté client comporte un problème implicite. Vous ne pouvez jamais vraiment savoir à l’avance quels genres de programmes la page que vous visitez va faire fonctionner. Si elle peut envoyer des informations de votre ordinateur vers d’autres, endommager quelque chose ou infiltrer votre système, surfer sur la toile pourrait être une activité bien hasardeuse.

Pour résoudre ce dilemme, les navigateurs limitent sévèrement les choses qu’un programme JavaScript peut faire. Il n’est pas permis de consulter vos fichiers ou de modifier quoi que ce soit d’étranger à la page web dont il provient. Isoler un environnement de programmation comme cela, se nomme sand-boxing (jouer dans le bac à sable). Offrir aux programmes suffisamment de place pour être utiles et en même temps les restreindre suffisamment pour les empêcher de faire du mal, n’est pas une chose simple à faire. Tous les quelques mois, un programmeur JavaScript découvre une nouvelle façon de contourner les limitations, de faire quelque chose de mal ou de transgresser les barrières qui entourent la vie privée. Les responsables des navigateurs répondent en modifiant leurs programmes pour rendre cette astuce impossible et tout va bien à nouveau ― jusqu’à ce que le prochain problème soit découvert.

Une des premières astuces de JavaScript qui devint largement utilisée est la méthode open de l’objet window. Elle prend une URL comme argument et ouvrira une nouvelle fenêtre affichant cette URL.

var perry = window.open("http://www.pbfcomics.com");

À moins que vous n’ayez désactivé le bloqueur de pop-up dans le chapitre 6, il y a une chance que cette nouvelle fenêtre soit bloquée. Il y a une bonne raison pour que les bloqueurs de pop-up existent. Les programmeurs web, particulièrement ceux qui essayent d’attirer l’attention des gens sur les publicités, ont tellement abusé de cette pauvre méthode window.open qu’à présent, la plupart des utilisateurs la détestent avec passion. Elle a son utilité pourtant et dans ce livre nous l’utiliserons pour afficher certains exemples de page. D’une manière générale, vos scripts ne devraient pas ouvrir de nouvelle fenêtre sauf quand l’utilisateur le demande.

Notez que parce qu’open (c’est également le cas de setTimeout et d’autres) est une méthode de l’objet window, la partie window. peut être enlevée. Quand une fonction est appelée « normalement », elle est appelée comme une méthode sur l’objet global, à savoir window. Personnellement, je pense que open semble un peu générique, donc généralement je tape window.open, qui indique clairement que c’est une fenêtre qui est en cours d’ouverture.

La valeur retournée par window.open est une nouvelle fenêtre. C’est l’objet global pour le script tournant dans cette fenêtre, et il contient toutes les choses standards comme le constructeur Object et l’objet Math. Mais si vous essayez d’y jeter un œil, la plupart des navigateurs ne vont (probablement) pas vous laisser faire…

show(perry.Math);

C’est la partie du sand-boxing que j’ai mentionnée plus tôt. Les pages ouvertes par votre navigateur peuvent afficher des informations qui vous sont seulement destinées, par exemple sur des sites où vous vous êtes identifiés, et il serait donc mauvais que n’importe quel script au hasard puisse y aller et les lire. L’exception à cette règle, ce sont les pages ouvertes pour le même domaine : quand un script tournant sur une page de eloquentjavascript.net ouvre une autre page de ce même domaine, il peut faire tout ce qu’il veut sur cette page.

Une fenêtre ouverte peut être fermée avec sa méthode close. Si vous ne l’avez pas déjà fermée vous-même…

perry.close();

D’autres types de sous-documents, comme les frames (documents dans un document) sont aussi des fenêtres du point de vue d’un programme JavaScript et ont leur propre environnement JavaScript. En fait, l’environnement auquel vous avez accédé dans la console appartient à une petite frame invisible quelque part dans cette page ― de cette manière, il est un petit peu plus difficile pour vous d’accidentellement mettre la pagaille dans toute la page.

Chaque objet fenêtre a une propriété document, qui contient un objet représentant le document affiché dans la fenêtre. Cet objet contient, par exemple, une propriété location, avec des informations sur l’URL du document.

show(document.location.href);

Mettre document.location.href à une nouvelle URL peut être utilisé pour demander au navigateur de charger un autre document. Une autre application de l’objet document est sa méthode write. Cette méthode, quand on lui donne un argument texte, écrit du HTML dans le document. Quand c’est utilisé dans un document totalement chargé, cela remplacera le document complet par le HTML donné, ce qui n’est généralement pas ce que vous voulez. L’idée est d’avoir un script l’appelant pendant que le document est en cours de chargement, dans ce cas le HTML écrit sera inséré dans le document à l’endroit où la balise script l’a déclenché. C’est une manière simple d’ajouter des éléments dynamiques à une page. Par exemple, voici un document carrément simple affichant l’heure courante.

print(horlogeParlante);
var temps = viewHTML(horlogeParlante);

temps.close();

Souvent, la technique affichée dans le chapitre 12 fournit une manière plus propre et plus souple de modifier un document, mais occasionnellement, document.write est la manière la plus belle et la plus simple de le faire.

Une autre application populaire du JavaScript dans les pages web tourne autour des formulaires. Dans les cas où vous ne seriez pas tout à fait sûr du rôle des « formulaires », laissez-moi vous présenter un résumé rapide.

Une requête HTTP élémentaire est une simple requête pour un fichier. Quand ce fichier n’est pas vraiment un fichier passif, mais un programme côté serveur, il peut devenir utile d’inclure des informations autres qu’un nom de fichier dans la requête. Pour cela, les requêtes HTTP sont autorisées à contenir des « paramètres » additionnels. Voici un exemple:

http://www.google.com/search?q=empire%20aztec

Après le fichier (/search), l’URL continue avec un point d’interrogation, suivi de paramètres. Cette requête a un paramètre, nommé q (vraisemblablement pour "query", c’est-à-dire requête), dont la valeur est empire aztec. La partie %20 correspond à une espace. Il y a nombre de caractères qui peuvent apparaître dans ces valeurs, comme les espaces, les esperluettes ou les points d’interrogation. Ceux-ci sont remplacés par un % suivi par une valeur numérique 1, ce qui a la même fonction que les antislash utilisés dans les textes et expressions rationnelles, mais est encore plus illisible.

JavaScript fournit les fonctions encodeURIComponent et decodeURIComponent pour ajouter ces codes aux textes et également les enlever.

var encode = encodeURIComponent("empire aztec");
show(encode);
show(decodeURIComponent(encode));

Quand une requête contient plus d’un paramètre, ils sont séparés par une esperluette, comme dans…

http://www.google.com/search?q=empire%20aztec&lang=fr

Un formulaire, essentiellement, est une manière de rendre facile aux utilisateurs des navigateurs la création de ces URL paramétrées. Il contient un nombre de champs, comme des boîtes d’entrée de texte, des cases à cocher qui peuvent être « cochées » et « décochées » ou des bidules permettant de choisir parmi un ensemble de valeurs. Il contient en général aussi un bouton de « soumission » et, invisible à l’utilisateur, une URL « action » à laquelle il sera envoyé. Quand on clique sur le bouton « soumettre » ou qu’on appuie sur la touche Entrée, les informations qui ont été saisies dans les champs sont ajoutées comme paramètres à cette URL action, et le navigateur va demander cette URL.

Voici le HTML pour un formulaire simple :

<form name="info_utilisateur" method="get" action="info.html">
  <p>S’il vous plaît donnez-nous vos informations, afin que nous puissions vous envoyer du spam.</p>
  <p>Nom: <input type="text" name="nom"/></p>
  <p>courriel: <input type="text" name="email"/></p>
  <p>Sexe: <select name="sexe">
            <option>Homme</option>
            <option>Femme</option>
            <option>Autre</option>
          </select></p>
  <p><input name="envoyer" type="submit" value="Envoyer !"/></p>
</form>

Le nom du formulaire peut être utilisé pour y accéder avec JavaScript, comme nous allons le voir dans un moment. Les noms des champs déterminent les noms des paramètres HTTP qui sont utilisés afin de stocker leurs valeurs. Envoyer ce formulaire peut produire une URL comme ceci:

http://planetspam.com/info.html?nom=Ted&email=ted@zork.com&sexe=Homme

De nombreuses autres balises et propriétés qui peuvent être utilisés dans les formulaires mais nous nous en tiendrons dans ce livre aux plus simples, afin de nous concentrer sur le JavaScript.

La propriété method="get" du formulaire d’exemple ci-dessus indique que ce formulaire doit encoder les valeurs qu’on lui donne en tant que paramètres d’URL, comme montré avant. Il existe une méthode alternative pour envoyer les paramètres, qui s’appelle post. Une requête HTTP utilisant la méthode post contient, en plus d’une URL, un bloc de données. Un formulaire utilisant la méthode post met les valeurs de ses paramètres dans ce bloc de données plutôt que dans l’URL.

Quand on envoie de grandes quantités de données, la méthode get va générer des URL d’un kilomètre de long, donc post est généralement plus pratique. Mais la différence entre les deux méthodes n’est pas juste une question de convenance. Traditionnellement, les requêtes get sont utilisées pour demander un document au serveur, alors que les requêtes post sont utilisées pour déclencher une action qui change quelque chose sur le serveur. Par exemple, obtenir une liste des messages récents d’un forum Internet serait une requête get, alors qu’ajouter un nouveau message serait une requête post. Il y a une bonne raison pour laquelle la plupart des pages suivent cette distinction ― les programmes qui explorent automatiquement le web, comme ceux utilisés par les moteurs de recherche, vont généralement seulement faire des requêtes get. Si des changements sur un site peuvent être faits par une requête get, ces robots d’exploration bien intentionnés pourraient faire pas mal de dégâts.

Quand le navigateur affiche une page contenant un formulaire, les programmes JavaScript peuvent inspecter et modifier les valeurs qui sont entrées dans les champs du formulaire. Cela ouvre des possibilités pour toutes sortes d’astuces, comme vérifier les valeurs avant qu’elles ne soient envoyées au serveur ou remplir automatiquement certains champs.

Le formulaire affiché ci-dessus peut être trouvé dans le fichier example_getinfo.html. Ouvrez-le.

var formulaire = window.open("example_getinfo.html");

Quand une URL ne contient pas un nom de serveur, elle est appelée URL relative. Les URL relatives sont interprétées par le navigateur pour référencer des fichiers sur le même serveur que le document en cours. À moins qu’il ne commence par un slash, le chemin (ou répertoire) du document en cours est aussi conservé et le chemin donné lui est ajouté.

Nous ajouterons une vérification de validité au formulaire, afin qu’il soumette seulement si le champ nom n’est pas laissé vide et si le champ courriel contient quelque chose qui ressemble à une adresse électronique valide. Parce que nous ne voulons plus que le formulaire soit soumis immédiatement quand le bouton « Envoyer ! » est cliqué. Sa propriété type a été changée de "submit" à "button", ce qui le change en un bouton ordinaire sans aucun effet. ― Le chapitre 13 montrera une bien meilleure manière de faire ceci, mais pour l’instant, nous utilisons la méthode naïve.

Afin de travailler avec la fenêtre nouvellement ouverte (si vous l’avez fermée, rouvrez-la d’abord), nous lui « attachons » la console, comme ceci:

attach(formulaire);

Après avoir fait ceci, le code lancé de la console tournera dans la fenêtre donnée. Pour vérifier que nous fonctionnons effectivement avec la bonne fenêtre, nous pouvons regarder les propriétés location et title du document.

print(document.location.href);
print(document.title);

Étant donné que nous avons entré un nouvel environnement, les variables précédemment définies, comme formulaire, ne sont plus présentes.

show(formulaire);

Pour revenir à notre environnement de départ, nous pouvons utiliser la fonction detach (sans argument). Mais d’abord, nous avons à ajouter le système de validation au formulaire.

Toute balise HTML affichée dans un document a un objet JavaScript associé. Ces objets peuvent être utilisés pour inspecter et manipuler presque tout aspect du document. Dans ce chapitre, nous allons travailler avec les objets pour formulaires et champs de formulaire. Le chapitre 12 traite de façon plus détaillée de ces objets.

L’objet document a une propriété nommée forms, qui contient des liens vers tous les formulaires du document, par nom. Notre formulaire a une propriété name="info_utilisateur", afin d’être trouvable sous la propriété info_utilisateur.

var formulaireUtilisateur = document.forms.info_utilisateur;
print(formulaireUtilisateur.method);
print(formulaireUtilisateur.action);

Dans ce cas, les propriétés method et action qui ont été données à la balise HTML form sont aussi présentes comme propriétés de l’objet JavaScript. C’est souvent le cas, mais pas toujours: Certaines propriétés HTML sont orthographiées différemment en JavaScript, d’autres ne sont pas présentes du tout. Le chapitre 12 exposera un moyen d’obtenir toutes les propriétés.

L’objet de la balise form a une propriété elements, qui se réfère a un objet contenant les champs du formulaire, par nom.

var champsNom = formulaireUtilisateur.elements.nom;
champsNom.value = "Eugène";

Les objets d’entrée texte ont une propriété value, qui peut être utilisée pour lire et changer leur contenu. Si vous regardez la fenêtre du formulaire après le fonctionnement du code ci-dessus, vous verrez que le nom a été rempli.

Tout ce que nous avons à faire maintenant est de déterminer ce qui arrive quand les gens cliquent sur le bouton « Envoyer ! ». Pour l’instant, il ne se passe rien du tout. Cela sera corrigé en réglant sa propriété onclick.

formulaireUtilisateur.elements.envoyer.onclick = function() {
  alert("Clic !");
};

Tout comme les actions données à setInterval et setTimeout (chapitre 8), la valeur stockée dans une propriété onclick (ou similaire) peut être soit une fonction soit une chaîne de code JavaScript. Dans ce cas, nous lui donnons une fonction qui ouvre une fenêtre d’alerte. Essayez de la sélectionner.

Une autre astuce liée aux entrées de formulaire, ainsi que d’autres choses qui peuvent être « sélectionnées », comme les boutons ou liens, est la méthode focus. Quand vous savez avec certitude qu’un utilisateur voudra saisir dans un certain champ dès qu’il entre dans la page, vous pouvez faire en sorte que votre script y place le curseur, afin qu’il n’ait pas à cliquer pour le sélectionner d’une quelconque manière.

formulaireUtilisateur.elements.nom.focus();

Puisque le formulaire est dans une autre fenêtre, il n’est pas forcément évident que quelque chose ait été sélectionné, cela dépend du navigateur que vous utilisez. Certaines pages vont aussi automatiquement faire passer le curseur sur le champ suivant quand il semble que vous ayez fini de remplir un champ ― par exemple, quand vous tapez un code postal. Ceci ne devrait pas être fait de manière exagérée ― cela donne à la page un comportement auquel l’utilisateur ne s’attend pas. S’il est habitué à la tabulation pour déplacer le curseur manuellement ou a fait une erreur sur le dernier caractère et veut l’enlever, ce curseur sauteur magique est très ennuyeux.

detach();

Testez le validateur. Quand vous entrez une information valide et cliquez sur le bouton, le formulaire devrait se soumettre. Si la console y est toujours attachée, cela la fera se détacher, car la page se rechargera et l’environnement JavaScript sera remplacé par un nouveau.

Si vous n’avez pas encore clos la fenêtre de formulaire, ceci la fermera.

formulaire.close();

Cela peut sembler simple, mais je vous assure que la programmation côté client n’est pas de tout repos. Cela peut même parfois être une épreuve douloureuse. Pourquoi ? Parce que les programmes qui sont supposés tourner sur l’ordinateur client doivent généralement fonctionner dans les navigateurs les plus populaires. Chacun de ces navigateurs a tendance à fonctionner de manière légèrement différente. Pour rendre les choses plus complexes, chacun d’entre eux contient son propre ensemble de problèmes. Ne présumez pas qu’un programme est sans bug juste parce qu’il a été fait par une entreprise qui pèse plusieurs milliards de dollars. Donc il nous revient à nous, développeurs web, de rigoureusement tester nos programmes, d’arriver à comprendre ce qui va pas et de trouver des manières de contourner les problèmes.

Certains d’entre vous peuvent penser « Je vais juste remonter tous les problèmes/bugs que je trouve aux fabricants du navigateur et ils vont certainement les résoudre immédiatement ». Ces gens se préparent à une grosse déception. Les plus récentes versions d’Internet Explorer, le navigateur qui est toujours utilisé par quelque soixante dix pour cent des surfeurs de la toile (et que chaque développeur web aime à taquiner) contient toujours des bugs qui sont connus depuis plus de cinq ans. De sérieux bugs en plus.

Mais que cela ne vous décourage pas. Avec un état d’esprit du genre obsessionnel-compulsif comme il convient, de tels problèmes lancent des défis merveilleux. Et pour ceux d’entre vous qui n’aiment pas perdre leur temps, être prudent et éviter les recoins obscurs des fonctionnalités du navigateur vous évitera de tomber sur des problèmes trop embarrassants.

À part les bugs, les différences de conception d’interface entre navigateurs produisent un défi intéressant. La situation en cours ressemble à quelque chose comme ceci : d’un côté, il y a tous les « petits » navigateurs : Firefox, Safari et Opéra sont les plus importants mais il en existe d’autres. Ces navigateurs font tous un effort raisonnable pour adhérer à un ensemble de standards qui ont été développés ou sont en train d’être développés, par le W3C, une organisation qui essaie de faire de la toile un environnement moins désordonné en définissant des interfaces standards pour des choses comme ceci. D’un autre côté, il y a Internet Explorer, le navigateur de Microsoft, qui a grandi jusqu’à dominer à une époque quand la plupart de ces standards n’existaient pas vraiment encore et n’a guère fait d’efforts pour s’ajuster à ce que les autres font.

Dans certains domaines, tels que la façon dont le contenu d’un document HTML peut être interprété par le JavaScript (chapitre 12), les standards sont basés sur la méthode inventée par Internet Explorer et les choses marchent plus ou moins de la même façon pour tous les navigateurs. Dans d’autres domaines, tels que la façon dont les évènements sont gérés (clic de souris, touche du clavier enfoncée et autres), Internet Explorer fonctionne différemment des autres.

Pendant longtemps, en partie à cause du manque de jugeote du développeur JavaScript moyen, en partie à cause des incompatibilités entre navigateurs qui étaient bien pires quand les navigateurs comme Internet Explorer versions 4 et 5 et les vieilles versions de Netscape étaient encore fréquentes, la manière habituelle de gérer de telles différences était de détecter quel navigateur l’utilisateur faisait tourner et de disperser dans le code des solutions alternatives pour chaque navigateur ― si c’est Internet Explorer, fais ceci, si c’est Netscape, fais cela, et si c’est n’importe quel autre navigateur auquel nous n’avons pas pensé, garde l’espoir que tout se passera pour le mieux. Vous pouvez imaginer à quel point ces programmes étaient hideux, obscurs et longs.

Nombre de sites pouvaient aussi refuser de se charger quand ils étaient ouverts dans un navigateur qui n’était « pas supporté ». Cela obligea quelques-uns des navigateurs mineurs à ravaler leur fierté et prétendre qu’ils étaient Internet Explorer, juste assez pour être autorisés à charger de telles pages. Les propriétés de l’objet navigator contiennent des informations sur le navigateur dans lequel une page a été chargée, mais à cause de ces mensonges cette information n’est pas particulièrement fiable. Voyez ce que dit le vôtre2:

forEachIn(navigator, function(nom, valeur) {
  print(nom, " = ", valeur);
});

Une meilleure approche consiste à essayer « d’isoler » nos programmes des différences entre navigateurs. Si vous devez, par exemple, en découvrir plus sur un évènement, comme le clic que nous avons géré en modifiant la propriété onclick de notre bouton d’envoi, vous devez regarder l’objet de l’environnement global nommé event dans Internet Explorer, mais vous devez utiliser le premier argument passé à la fonction gérant cet évènement dans les autres navigateurs. Pour gérer ceci, et nombre d’autres différences liées aux évènements, on peut écrire une fonction d’aide pour attacher les évènements aux choses, elle prendra soin de toute la plomberie et permettra aux fonctions de gestion d’évènements d’être les mêmes pour tous les navigateurs. Dans le chapitre 13 nous écrirons une fonction de ce genre.3

Ces chapitres ne donneront qu’une introduction superficielle du sujet des interfaces des navigateurs. Elles ne sont le principal sujet de ce livre et elles sont suffisamment complexes pour remplir un livre par elles-mêmes. Quand vous aurez compris les bases de ces interfaces (et compris quelque chose à propos d’HTML), ce ne sera pas trop difficile de rechercher des informations spécifiques en ligne. Les documentations des interfaces des navigateurs Firefox et Internet Explorer constituent de bons points de départ.

Les informations dans les prochains chapitres n’aborderont pas les caprices des navigateurs de « génération antérieure ». Elles parlent d’Internet Explorer 6, Firefox 1.5, Opera 9, Safari 3, ou n’importe quelle version plus récente de ces mêmes navigateurs. La plus grande part sera aussi applicable aux modernes mais obscurs navigateurs comme Konqueror, mais cela n’a pas été complètement vérifié. Heureusement, ces navigateurs de génération antérieure ont plus ou moins disparu, et ne sont plus guère utilisés.

Il y a, malgré tout, un groupe d’utilisateurs web qui vont toujours utiliser un navigateur sans JavaScript. Une large part de ce groupe est constitué de personnes utilisant un navigateur graphique usuel, mais avec JavaScript désactivé pour des raisons de sécurité. Ensuite ceux qui utilisent des navigateurs textes, ou navigateurs pour personnes aveugles. Quand on travaille sur un site « sérieux », c’est une bonne idée de commencer par un simple système HTML qui fonctionne et ensuite d’ajouter des bidouilles non essentielles et des trucs pratiques avec JavaScript.