Il vous arrivera sûrement qu'après une modification (correction?) de votre script, aucun changement ne soit visible à l'écran après avoir fait "Reload" ou "Actualiser".

• Vérifier bien si vous avez enregistré vos modifications (cela arrive même aux meilleurs).
• Il faut parfois recharger plus profondément votre page en faisant Shift + Reload (sous Netscape) ou cliquez dans la zone de localisation du browser et faire Enter.

Microsoft Explorer 3.0 supporte une forme de Javascript. Microsoft a implanté le langage Javascript séparément et indépendamment de Netscape. Internet Explorer "comprend" le code Javascript, mais son implémentation n'est pas complète. Il faut garder cela à l'esprit lorsque on veut écrire du code Javascript qui doit fonctionner à la fois sous Netscape et Explorer 3.0.

Votre code Javascript sous Explorer doit

• impérativement être du Javascript 1.0. Toutes les fonctions Javascript 1.1, si familières pour Netscape 3, entraîneront des messages d'erreur.
• ne pas faire appel à des applications Javascript sophistiquées.
• s'armer de patience car certains codes Javascript élémentaires fonctionnant à merveille sous Netscape, devront être réécrits avec une syntaxe plus stricte.

Pour corser le tout, Microsoft conscient des lacunes de son browser, a sorti une évolution de son interpréteur Javascript. On voit ainsi apparaître fin 97, une JScript.dll version 2. Celle-ci apporte une meilleure compatibilté avec Netscape 3 (comme les objets Array (les tableaux)). Comprendre Explorer 3.0 et Javascript n'était déjà pas simple mais nous voilà maintenant avec du Javascript sous Explorer 3.0 avec la JScript.dll version 1 et la JScript.dll version 2! Quel plaisir ...

Pour Microsoft Explorer 4.0, celui-ci adhère strictement au standard appelé ECMAScript, qui couvre essentiellement la version Javascript 1.1. A fin novembre 97, il est encore un peu tôt pour se faire une idée précise mais il est déjà évident que Microsoft Explorer 4.0 intègre beaucoup mieux (ou très bien ?) le Javascript.

Dans le détail -- et je reprends ce qui suit du site de Danny Goodman (www.dannyg.com) qui est "La" référence en Javascript -- :

Objets non supportés par Explorer 3.0

• L'objet Image[]. Donc pas de onmouseOver sous Explorer 3.
• Pour l'objet Area pas de ommouseOver.
• Pas d'Applet
• Pour les tableaux, écriture stricte Javascript 1.0 pour la version 1. Mais l'objet Array est implanté avec la version 2.
• ...

Propriétés, méthodes, gestionnaires d'événement non supportés

• Window
  onerror closed blur() focus() scroll() onBlur= onFocus=
• Location
  reload() replace()
• Document
  applets[] domain embeds[] images[] URL
• Link
  onMouseOut=
• Form
  reset() onReset=
• (All Form Elements)
  type
• Navigator
  mimeTypes[] plugins[] javaEnabled()
• String
  prototype split()

Javasript dans des tableaux, ce n'est pas une histoire d'amour (bug?). On recommande dans la littérature de ne pas placer de tag <SCRIPT> dans des balises <TD> mais plutôt de commencer le tag <SCRIPT> avant le tag <TD> et d'écrire le tag <TD> jusqu'au tag </TD> par une écriture document.write. Et même, pour être sur de son coup, d'écrire tout la tableau avec le document.write. Ce qui donnerait :

<SCRIPT LANGUAGE="Javascript">
<!--
document.write("<TABLE BORDER=1>");
document.write("<TR>");
document.write("<TD>");
document.write("votre texte");
document.write("</TD>");
document.write("<TD>");
document.write("votre texte");
document.write("</TD>");
document.write("</TR>");
document.write("</TABLE>");
//-->
</SCRIPT>

En conclusion, au niveau débutant, éviter de mettre du Javascript dans des tableaux. Ajoutons qu'il n'y a pas de problèmes pour les formulaires. Mais est-ce vraiment du Javascript?...

Avec les méthodes et propriétés de l'objet navigator (voir ce chapitre), il y aura moyen de détecter le type et la version du browser. Ce qui sera très utile pour adapter vos scripts au browser et à la version de celui-ci.

La compatibilité des pages Javascript avec les différents types et versions en circulation pose vraiment problème. A l'avenir, on peut espérer une mutation rapide vers Explorer 4 pour les partisans de Microsoft et l'abandon progressif de Netscape 2.0 pour des versions plus récentes. Ce qui simplifiera grandement la situation.
Si vous n'êtes pas obnubilés par la compatiblité de vos pages de script (et les messages d'erreurs qui risquent d'apparaître), soyez quand même sympa d'avertir vos lecteurs. Ainsi, le petit script suivant informe les utilisateurs de Explorer 3.0 qu'ils risquent de rencontrer quelques désagréments.
<SCRIPT LANGUAGE = "JavaScript">
<!--
var name = navigator.appName ;
if (name == 'Microsoft Internet Explorer') {
document.write('Attention! Vous utilisez Microsoft Explorer 3.0.') <BR>');
document.write('Avec ce browser, certains scripts peuvent ne pas fonctionner correctement');
}
else { null }
//-->
</SCRIPT>

Pour des informations très complètes sur les différentes versions de Javascript, je ne peux que vous conseiller vivement "JavaScript Object Road Map and Compatibility Guide", quatre feuillets que l'on peut télécharger sur le site de Danny Goodman ("La" référence !) à l'adresse www.dannyg.com.

Il arrive que Javascript vous affiche un résultat de division du type 1.599999999999999. Ce qui est assez disgracieux, j'en conviens. Nous approfondirons le sujet lors de l'étude de la méthode Math. Parmi les différents systèmes possibles , je vous propose celui-ci :

variable= Math.round (variable*100)/100
Ainsi, 1.599999 est multiplié par 100 ce qui fait 159.9999. La méthode Math.round (159.9999) donne 160, qui divisé par 100 fait 1.60. Avec ...*100)/100, on obtient 2 chiffres après la virgule. Devinez pour 3 chiffres après la virgule...

Il est impossible de lire un fichier ou d'écrire dans un fichier en Javascript. C'est sûrement très bien pour la sécurité de votre système mais c'est dommage pour, par exemple, l'exploitation d'une base de données.

Et oui, par "View Document Source", le lecteur un peu initié pourra voir, étudier, copier vos sources Javascript. Il existe sur le net plusieurs petits programmes de codage des scripts, d'appels à des fichiers dissimulés, etc. Je suis arrivé à la conclusion que aucun système ne pourra garantir une confidentialité absolue de vos scripts. Si pour les entreprises, cela peut être gênant pour des données sensibles (mais il y a alors d'autres techniques disponibles, je pense à du Java), pour les simples particuliers on peut se demander si cela a vraiment de l'importance... Ne seriez vous pas un peu paranoïaque ? Si oui, il y a toujours moyen de coder votre Javascript d'une façon (presque) incompréhensible pour le programmeur moyen.

Vos variables sont définies dans le script de l'entité que constitue votre page Web. Vous pouvez souhaiter continuer à utiliser ces variables dans une autre page ou tout au long de votre site. Comment faire? La solution est d'utiliser des frames. Javascript permet de passer des variables d'un frame vers des objets appartenant à un autre frame. Et comme tous les browsers Javascript admettent des frames, pourquoi s'en priver (voir un des chapitres suivant).

Ce bug propre à Netscape 2, peut vous jouer de grosses surprises par exemple dans un formulaire de commande utilisant des boutons radio. En effet si le bouton radio 1 d'une série de 3 est checked, c'est la valeur 3 qui est retournée. Pour vous, le client a commandé une chemise Large alors qu'il souhaitait du Small !
Pour corriger ce bug, il suffit d'ajouter un gestionnaire d'événement vide à chaque contrôle de la série de boutons radio.
<FORM NAME="radioTest">
<INPUT TYPE="radio" NAME="test" VALUE="A" onClick="">A
<INPUT TYPE="radio" NAME="test" VALUE="B" onClick="">B
<INPUT TYPE="radio" NAME="test" VALUE="C" onClick="">C
</FORM>