j'ai une zone de formulaire qui permet à un visiteur d'entrer un numéro
de msg (donnée par une image) pour éviter le spamming...
Si une erreur est détectée dans le formulaire, celui-ci est affiché de
nouveau, le numéro aléatoire est modifié (heureusement...) mais si la
navigateur de l'utilisateur le permet, l'ancien numéro reste dans la
zone de saisie.... pas trop grave, mais par manque d'attention , il
pourrait ne pas être modifié par l'utilisateur..... comment forcer la
zone à vide à l'affichage... et biaiser le navigateur ?
Ensuite bien évidemment ils font toujours appel à l'attribut "autocomplete" qui n'existe pas.
Qui n'est pas standard, plutôt.
Soit, mais si je me place du point de vue d'un agent utilisateur qui ne le reconnaît pas, il n'existe pas. En l'occurence le script pourrait vérifier le support de cet attribut avant d'essayer d'agir dessus mais il ne le fait pas.
La page est donc toujours invalide (le DOM généré par JavaScript est invalide dès l'ajout de cet attribut bidon à l'arbre du document) et de plus toute la méthode repose sur un attribut qui ne sera que rarement reconnu (qui utilise encore IE ;) ? ).
En quoi l'ajout d'une propriété JavaScript rend-elle invalide le DOM ? Le DOM précise (entre autres) les propriétés et méthodes qui *doivent* être implémentées mais je n'ai pas lu que cette liste était limitative, et encore moins que les encapsulations que JS fait des objets DOM soit susceptibles de le casser.
Je me suis mal exprimé (les newsgroups devraient être reliés à des machines à claques) : c'est le document qui est invalide, car c'est lui qu'on manipule et non pas le DOM.
Le document généré via le DOM n'est ni plus moins qu'un document (X)HTML. Ajouter un attribut non valide, via le DOM ou pas, rend le document invalide. Dès qu'on a modifié l'arbre du document via JavaScript, le document que l'on voit en faisant "afficher source" n'est plus le document affiché et exploité par le navigateur.
Personnellement, j'aurais plutôt choisi de tester l'existence de cet attribut avant de le positionner :
Comme je l'ai dit plus haut, il vaut mieux tester si l'attribut est pris en charge par l'agent (d'autant plus en cas d'attribut non standard), car dans le cas contraire le manipuler peut avoir des résultats inattendus.
Sébastien
Ensuite bien évidemment ils font toujours appel à l'attribut
"autocomplete" qui n'existe pas.
Qui n'est pas standard, plutôt.
Soit, mais si je me place du point de vue d'un agent utilisateur qui ne
le reconnaît pas, il n'existe pas.
En l'occurence le script pourrait vérifier le support de cet attribut
avant d'essayer d'agir dessus mais il ne le fait pas.
La page est donc toujours invalide (le DOM généré par JavaScript est
invalide dès l'ajout de cet attribut bidon à l'arbre du document) et
de plus toute la méthode repose sur un attribut qui ne sera que
rarement reconnu (qui utilise encore IE ;) ? ).
En quoi l'ajout d'une propriété JavaScript rend-elle invalide le DOM ?
Le DOM précise (entre autres) les propriétés et méthodes qui *doivent*
être implémentées mais je n'ai pas lu que cette liste était limitative,
et encore moins que les encapsulations que JS fait des objets DOM soit
susceptibles de le casser.
Je me suis mal exprimé (les newsgroups devraient être reliés à des
machines à claques) : c'est le document qui est invalide, car c'est lui
qu'on manipule et non pas le DOM.
Le document généré via le DOM n'est ni plus moins qu'un document
(X)HTML. Ajouter un attribut non valide, via le DOM ou pas, rend le
document invalide. Dès qu'on a modifié l'arbre du document via
JavaScript, le document que l'on voit en faisant "afficher source" n'est
plus le document affiché et exploité par le navigateur.
Personnellement, j'aurais plutôt choisi de tester l'existence de cet
attribut avant de le positionner :
Comme je l'ai dit plus haut, il vaut mieux tester si l'attribut est pris
en charge par l'agent (d'autant plus en cas d'attribut non standard),
car dans le cas contraire le manipuler peut avoir des résultats inattendus.
Ensuite bien évidemment ils font toujours appel à l'attribut "autocomplete" qui n'existe pas.
Qui n'est pas standard, plutôt.
Soit, mais si je me place du point de vue d'un agent utilisateur qui ne le reconnaît pas, il n'existe pas. En l'occurence le script pourrait vérifier le support de cet attribut avant d'essayer d'agir dessus mais il ne le fait pas.
La page est donc toujours invalide (le DOM généré par JavaScript est invalide dès l'ajout de cet attribut bidon à l'arbre du document) et de plus toute la méthode repose sur un attribut qui ne sera que rarement reconnu (qui utilise encore IE ;) ? ).
En quoi l'ajout d'une propriété JavaScript rend-elle invalide le DOM ? Le DOM précise (entre autres) les propriétés et méthodes qui *doivent* être implémentées mais je n'ai pas lu que cette liste était limitative, et encore moins que les encapsulations que JS fait des objets DOM soit susceptibles de le casser.
Je me suis mal exprimé (les newsgroups devraient être reliés à des machines à claques) : c'est le document qui est invalide, car c'est lui qu'on manipule et non pas le DOM.
Le document généré via le DOM n'est ni plus moins qu'un document (X)HTML. Ajouter un attribut non valide, via le DOM ou pas, rend le document invalide. Dès qu'on a modifié l'arbre du document via JavaScript, le document que l'on voit en faisant "afficher source" n'est plus le document affiché et exploité par le navigateur.
Personnellement, j'aurais plutôt choisi de tester l'existence de cet attribut avant de le positionner :
Comme je l'ai dit plus haut, il vaut mieux tester si l'attribut est pris en charge par l'agent (d'autant plus en cas d'attribut non standard), car dans le cas contraire le manipuler peut avoir des résultats inattendus.
Sébastien
ASM
Personnellement, j'aurais plutôt choisi de tester l'existence de cet attribut avant de le positionner :
Comme je l'ai dit plus haut, il vaut mieux tester si l'attribut est pris en charge par l'agent (d'autant plus en cas d'attribut non standard), car dans le cas contraire le manipuler peut avoir des résultats inattendus.
à partir de quelle version du JS cet autocomplete a t-il fait son apparition ?
Amha, il serait de bon ton de commencer par un test(*) de reconnaissance du javascript lié au DOM. Ce serait idéal de pouvoir déclarer ce JS Domesque à l'interieur de balises non interprétées par les anciens navigateurs. Existe-ce ?
(*) que je vois très rarement assuré ... !
-- Stephane Moriaux et son [moins] vieux Mac
Personnellement, j'aurais plutôt choisi de tester l'existence de cet
attribut avant de le positionner :
Comme je l'ai dit plus haut, il vaut mieux tester si l'attribut est pris
en charge par l'agent (d'autant plus en cas d'attribut non standard),
car dans le cas contraire le manipuler peut avoir des résultats inattendus.
à partir de quelle version du JS cet autocomplete a t-il fait son
apparition ?
Amha, il serait de bon ton de commencer par un test(*) de reconnaissance
du javascript lié au DOM.
Ce serait idéal de pouvoir déclarer ce JS Domesque à l'interieur de
balises non interprétées par les anciens navigateurs. Existe-ce ?
Comme je l'ai dit plus haut, il vaut mieux tester si l'attribut est pris en charge par l'agent (d'autant plus en cas d'attribut non standard), car dans le cas contraire le manipuler peut avoir des résultats inattendus.
à partir de quelle version du JS cet autocomplete a t-il fait son apparition ?
Amha, il serait de bon ton de commencer par un test(*) de reconnaissance du javascript lié au DOM. Ce serait idéal de pouvoir déclarer ce JS Domesque à l'interieur de balises non interprétées par les anciens navigateurs. Existe-ce ?
