Webnaute.net est à nouveau fonctionnel ! Le serveur sur lequel est hébergé le site a subi plusieurs attaques la semaine dernière, avec pour conséquence une perte de données (15 Go) sur l’ensemble des sites hébergés. Dans le cas de webnaute.net du moins, la perte se limite aux logs Apache et aux statistiques web.

Il reste encore quelques petites choses à régler, notamment le sous domaine dev.webnaute.net à remettre en place. Je devrais avoir désormais un peu plus de temps à consacrer au site, donc ne lachez pas le fil ;-)

Une de mes dernières trouvailles : Un équivalent à l’incontournable DOM Inspector de Mozilla pour ce cher Internet Explorer est disponible sur cette page. Bon, j’ai dit équivalent mais je ne sais pas du tout ce que la bète a dans le ventre, je ne l’ai pas testé.

Je n’en avais pas fait un billet à l’époque, mais j’avais aussi déniché ce wiki dédié à Opera et fourmillant d’informations bien utiles. On peut y trouver notamment une Web-developper toolbar pour Opera à l’instar de celle existante pour Firefox (elle en est d’ailleurs inspirée), ainsi que, il me semble, un DOM Inspector, mais je n’arrive plus à remettre la main dessus…

Revenons d’ailleurs à celui de Firefox. Il reste relativement méconnu malgré ses grandes qualités, peut-être par manque de documentation ? Voici donc une présentation du DOM Inspector. Le document indique aussi comment s’en servir pour en tirer le meilleur parti. Y a pas à dire, c’est vraiment un magnifique outil. Je l’utilise depuis des mois, quoique de façon sporadique, et je n’ai découvert qu’il y a quelques semaines l’option permettant de ne pas voir apparaitre les nœuds #text vides (tabulation, sauts de ligne) dans la vue en arbre (option qui se trouve tout bètement dans le menu view ou vue pour la version française; Honte sur moi).

Je continue actuellement le développement de mon script de compatibilité pour faire fonctionner le DOM Events dans la plupart des navigateurs. Le script fonctionne bien (je l’utilise sur webnaute.net d’ailleurs).

J’ai tenté dernièrement de simuler l’attribut detail de l’objet Event sous MSIE. Dans le cas d’évènements liés à la souris et nécessitant une pression du doigt, cet attribut a une valeur par défaut de 1 et s’incrémente si l’évènement lié se produit de manière successive. Bref, si l’utilisateur effectue deux click successifs, nous aurons pour le second click Event.detail = 2.

J’ai pu faire quelque chose de fonctionnel. Là où le bât blesse, c’est que j’ai dù utiliser une valeur arbitraire comme intervalle de temps maximum entre deux évènements pour décider si ces deux évènements se suivent (et donc incrémenter Event.detail) ou non.

Alors je suis confronté à un choix difficile : Dois-je me contenter de ce que j’ai fait et donc garder cette valeur arbitraire (en sachant que l’intervalle entre deux click successifs est généralement réglable dans les préférences système) ? Ou bien faire marche arrière et me contenter de donner une valeur correcte à Event.detail pour un maximum de deux click successifs (je pourrai alors m’en sortir avec l’évènement dblclick) ?

Dans le premier cas, il restera un problème, car Opera semble refuser de déclencher plus de deux click successifs. Il se produit un léger blocage avant que cela refonctionne, mais trop tard pour considérer les évènements click ultérieures comme liés aux deux précédents (Je n’ai fait le test que sur un élément BUTTON pour l’instant).

Dans le second cas, la simulation de Event.detail ne sera parfaitement en accord avec la recommandation, laquelle ne donne pas de limite de déclenchements successifs. J’admet cependant que dans la pratique, cele n’est probablement pas utile en tout cas dans le cadre d’une page web, même une interaction basée sur deux click successifs est très rare. Je ne l’ai vu qu’une fois : C’était sur un wiki et le double click permettait d’accéder au formulaire de modification de la page en cours.

J’attend vos avis nombreux et éclairés.