Bonjour,
Marvin à abolument raison et ce raisonnement se généralise à tout événement javascript.
Il faut concevoir ton script comme une fonctionnalité ajoutée et non comme une nécessité.
Dans le cas d'un menu, il doit être implémenté par défaut déroulé à sa place naturelle, puis tu dois le replier par une routine javscript au chargement de la page.
Si ça n'est pas possible, notamment pour des raisons de gestion de la structure, l'absence des liens gérés par javascript ne doit pas être génante à la navigation et tu peux utiliser la solution de jb_gfx.
Attention toutefois de ne peut te retrouver obligé de compliquer inutilement la structure et d'éviter les redondances.
Le plus sage est quand même de considérer que si tu ne parviens pas à trouver une place pour dégrader ton menu de manière satisfaisante il vaut mieux retourner à la table à dessin, c'est très souvent le signe que les fondations de ton site pose problème.
Dernier conseil qui va de pair avec cette manière de faire : ton script de gestion de menu doit implémenter les events sur les éléments de menu au chargement de la page au travers du DOM et tu dois t'assurer du support des méthodes que tu utilise en les testant avant de lancer ton script.
Généralement un test sur un élement comme getElementById ou une méthode de l'objet Node (test plus sécurisant) suffit pour t'assurer de la version de javscript et du DOM présent chez le client.
Le résultat c'est que ton menu s'affiche déplié par défaut, qu'au chargement de la page la version de javascript et le support du DOM ou des méthodes critiques sont testés et que sous ces conditions une routine équipe les éléments des events (souris mais aussi clavier) nécessaires et replie le menu.
De cette manière, tu t'assures de ne pas poser de problème en cas d'absence ou de support partiel de javascript.
Ce n'est pas compliqué à faire mais ça demande un travail de conception généralement plus élaboré que les onmouse-machinchose et donc, il faut que ça en vailles le coup
Modifié le 27 Jan 2005 - 23:47